Connexion par code e-mail et Brevo

Vérification du backend déployé : 26 octobre 2026. Le transport configuré est MAIL_TRANSPORT=brevo. Il s'agit d'une observation de configuration, pas d'un test de délivrabilité : aucun e-mail n'a été envoyé pour rédiger cette page.

Qui fait quoi ?

Application Android / iOS
  -> POST /auth/email/request : adresse e-mail
  -> Backend : génération du code et conservation de son empreinte
  -> Brevo : envoi de l'e-mail contenant le code
  -> Utilisateur : saisie du code dans l'application
  -> POST /auth/email/verify : vérification côté backend
  -> Backend : délivrance du jeton utilisateur après validation

Les chemins ci-dessus sont les routes internes de l'API ; le point d'entrée public peut leur ajouter le préfixe /api.

Brevo envoie le message. Le backend Snag génère et vérifie le code, décide de l'accès au compte et délivre les jetons. Le frontend n'appelle pas directement Brevo et ne doit contenir ni sa clé API ni les secrets du serveur.

Le code est une preuve temporaire de contrôle de la boîte e-mail, pas le jeton utilisé ensuite pour accéder aux données. Le flux peut rattacher une adresse au compte anonyme existant ou connecter l'utilisateur au compte correspondant.

Configuration côté serveur

Variable	Rôle
MAIL_TRANSPORT	brevo pour l'envoi configuré sur le VPS lors du contrôle
MAIL_API_KEY	Clé secrète du fournisseur, réservée au backend
MAIL_FROM	Expéditeur configuré et accepté par le fournisseur
MAIL_REPLY_TO	Adresse de réponse facultative

Le code prend aussi en charge resend et console. Le mode console, utilisé par défaut si aucun transport n'est défini, écrit le code dans les logs et n'envoie aucun e-mail. Il n'est pas adapté à une connexion publique en production. Pour un transport réel, une clé ou un expéditeur absent/invalide provoque une erreur de configuration au démarrage.

Ne jamais copier les valeurs réelles dans Git, une capture, un ticket ou cette documentation. Une rotation de MAIL_API_KEY nécessite une mise à jour de la configuration du backend et sa prise en compte par le service ; aucun nouveau build mobile n'est nécessaire pour cette seule clé.

Protections observées dans le backend

• Code aléatoire à six chiffres, généré côté serveur.
• Validité de dix minutes et usage unique.
• Cinq tentatives maximum par code.
• Délai minimal de soixante secondes entre deux émissions pour une adresse.
• Limites de fréquence sur les routes de demande et de vérification.
• Empreinte salée avec scrypt en base, pas de code stocké en clair dans cette table.

Ces protections ne constituent pas une vérification d'authenticité du build. Une connexion e-mail valide prouve l'accès à une boîte, pas l'utilisation d'un frontend officiel ou l'autorisation de participer à une bêta privée.

Données et diagnostic

Brevo reçoit l'adresse du destinataire et le contenu du message, dont le code, pour assurer l'envoi. Cela doit être pris en compte dans l'inventaire des prestataires et des traitements de données ; cela ne lui donne pas accès à la collection de l'utilisateur ni aux identifiants de la base Snag.

Si le message n'arrive pas, vérifier le transport sélectionné, l'expéditeur, l'état de la clé et les événements de livraison chez le fournisseur, puis les indésirables. Ne pas publier les codes, clés ou messages complets dans les logs de diagnostic partagés. Un appel accepté par l'API ne garantit pas la réception de l'e-mail.

Références du code

Dans tcg-collector-backend :

• src/api/src/routes/authEmail.ts : demande et vérification.
• src/api/src/auth/loginCode.ts : génération, empreinte et règles du code.
• src/api/src/mail/mailer.ts : configuration et transports d'envoi.

Voir aussi Backend, API, images et autorisations.