E-mail et mot de passe

La stratégie par identifiants : l'utilisateur choisit un mot de passe, celui-ci est validé et haché côté serveur, et une session est émise en cas de correspondance. C'est la seule stratégie sur laquelle l'authentification à deux facteurs peut se greffer, car le TOTP s'enrôle sur un identifiant de type mot de passe.

auth:
  strategies:
    - type: emailAndPassword
      minPasswordLength: 12
      maxPasswordLength: 128
      requireEmailVerification: true
      autoSignIn: true

Chaque propriété est optionnelle — - type: emailAndPassword seul constitue une stratégie valide et fonctionnelle.

Propriétés

Propriété	Description
minPasswordLength	Longueur minimale du mot de passe, 6–128. Par défaut 8.
maxPasswordLength	Longueur maximale du mot de passe, 8–256. Par défaut 128.
requireEmailVerification	Booléen. Lorsque true, les utilisateurs doivent vérifier leur e-mail avant de se connecter. Par défaut false.
autoSignIn	Booléen. Lorsque true, les utilisateurs sont connectés automatiquement après l'inscription. Par défaut true.

Les deux bornes sont contrôlées à leurs propres extrêmes : minPasswordLength est rejeté hors de 6–128, et maxPasswordLength hors de 8–256 — une configuration ne peut donc pas exiger un minimum de 4 caractères.

Vérification avant connexion

Avec requireEmailVerification: true, l'inscription crée le compte mais pas de session utilisable. Sovrium envoie un e-mail de vérification rendu à partir du modèle verification, et la connexion est refusée tant que le lien n'a pas été suivi.

auth:
  strategies:
    - type: emailAndPassword
      requireEmailVerification: true
  emailTemplates:
    verification:
      subject: Confirm your email for MyApp
      text: 'Hi $name, confirm your email: $url'

C'est le réglage qui sépare « quiconque possède une boîte e-mail » de « quiconque sait taper une adresse ». Activez-le pour une inscription publique ; il importe moins lorsque les comptes sont créés par un administrateur, qui peut marquer l'adresse comme vérifiée dès la création.

Connexion automatique

autoSignIn vaut true par défaut : une inscription réussie émet immédiatement une session, si bien que l'utilisateur ne ressaisit jamais le mot de passe qu'il vient de choisir. Le passer à false le renvoie au formulaire de connexion — utile lorsque l'inscription est un acte privilégié que vous voulez ré-authentifier, et de fait inévitable lorsque requireEmailVerification est actif, puisqu'il n'y a encore rien où se connecter.

Réinitialisation du mot de passe

La réinitialisation est fournie avec la stratégie ; il n'y a rien à activer. Une demande envoie par e-mail un lien à usage unique rendu à partir du modèle resetPassword, et un administrateur peut aussi définir un mot de passe directement via POST /api/auth/admin/set-user-password — voir Gestion des utilisateurs.

Pages connexes

• Présentation des stratégies — le tableau strategies et comment choisir.
• Deux facteurs — le TOTP par-dessus cette stratégie.
• Modèles d'e-mail — les corps verification et resetPassword.
• Contrôle de l'inscription — si le public peut s'inscrire.
• Sessions — ce qu'émet une connexion réussie.