Tester les emails Supabase Auth avec InboxTap

Choisir Mailpit ou InboxTap selon le besoin

La CLI Supabase inclut Mailpit et expose par défaut son interface web sur localhost:54324. Conservez ce choix lorsqu’un développeur souhaite surtout examiner visuellement les modèles Auth locaux.

Choisissez InboxTap lorsque les tests automatisés tirent parti d’une adresse unique par cas, de waitForLink() ou waitForCode(), d’assertions sans contenu sensible, de règles de panne déterministes ou de preuves HTML et JSON bornées. Il s’agit d’un choix de méthode de test, pas d’une affirmation selon laquelle Supabase ne capturerait pas les emails locaux.

• Tests des emails Auth locaux avec Supabase ↗

Résoudre d’abord la topologie réseau

InboxTap se lie par défaut aux adresses de bouclage de la machine hôte. Un processus Supabase Auth exécuté dans un conteneur possède sa propre interface de bouclage : localhost dans ce conteneur ne désigne donc pas le processus InboxTap de l’hôte.

Ne configurez un SMTP personnalisé que dans une topologie où Auth peut atteindre l’écouteur sans exposer largement un service de capture sans authentification. Ne recopiez pas une liaison à 0.0.0.0 sur un poste partagé ou un réseau CI. De même, un projet Supabase hébergé ne peut pas joindre l’adresse de bouclage d’un ordinateur de développement.

Tester le message après la connexion SMTP

Une fois que la topologie Auth locale ou auto-hébergée choisie peut atteindre InboxTap, créez un destinataire et déclenchez signInWithOtp() par le véritable client Supabase. Malgré son nom, cette méthode envoie un lien magique par défaut ; le modèle d’email décide si l’utilisateur reçoit une URL de confirmation ou un code.

Supabase crée par défaut un utilisateur lorsque l’adresse est inconnue. Définissez shouldCreateUser sur false lorsque le produit réserve la connexion sans mot de passe aux comptes existants, et créez ce compte avant de demander son message.

Le lien de confirmation standard contient normalement le chemin de vérification Auth présenté dans l’extrait. Si le projet utilise un modèle PKCE personnalisé ou un autre point de rappel, filtrez et validez l’URL exigée par ce modèle plutôt que de coder la valeur par défaut en dur.

const inbox = await inboxTap.createInbox({ alias: "supabase-auth" });

const { error } = await supabase.auth.signInWithOtp({
  email: inbox.address,
});

if (error) throw error;

const confirmationUrl = await inbox.waitForLink({
  contains: "/auth/v1/verify",
  timeoutMs: 20_000,
});

• Documentation Supabase sur l’authentification par email sans mot de passe ↗

Respecter les modèles et les paramètres des OTP

La variable Token dans un modèle d’email Supabase produit un parcours OTP, tandis que l’URL de confirmation produit un parcours par lien. Testez le contrat rendu au lieu de le déduire du nom de la méthode cliente.

Supabase autorise les OTP par email de six à dix chiffres. waitForCode() dans InboxTap recherche exactement six chiffres par défaut : fournissez donc un motif pour une autre longueur. Le tableau pratique CapturedEmail.codes se limite aux séquences de quatre à huit chiffres ; un motif personnalisé de waitForCode() parcourt le corps et convient aux codes de neuf ou dix chiffres.

• Documentation Supabase sur les modèles d’email Auth ↗
• Configuration Auth de la CLI Supabase ↗

Séparer les tests locaux et hébergés

Le service d’envoi standard de Supabase hébergé restreint les destinataires et limite le débit, tandis qu’un SMTP personnalisé hébergé attend un serveur joignable sur le réseau avec des identifiants. InboxTap ne fournit volontairement ni accès public ni authentification SMTP : ce n’est donc pas un fournisseur SMTP pour un projet hébergé.

Utilisez InboxTap dans un environnement local ou CI isolé dont vous maîtrisez la frontière réseau. Choisissez un fournisseur de test ou de livraison authentifié adapté lorsqu’un projet Supabase hébergé doit envoyer sur le réseau public.

• Documentation Supabase sur le SMTP personnalisé ↗