Comment tester les liens magiques de bout en bout

Définir le contrat avant le test

Consignez l’expéditeur attendu, la famille de sujets, l’origine et le chemin de rappel, la durée de validité, le comportement d’inscription et la destination après connexion. Un fournisseur peut regrouper plusieurs mécanismes sans mot de passe sous le terme de lien magique, mais l’application reste responsable de l’URL exacte et de la politique de compte.

Décidez si une adresse inconnue peut créer un compte. Par exemple, l’extension de lien magique de Better Auth autorise l’inscription par défaut, sauf si disableSignUp est activé. Le test doit exprimer la décision du produit, et non hériter accidentellement d’une valeur par défaut du fournisseur.

• Comportement des liens magiques dans Better Auth ↗
• Authentification Supabase sans mot de passe par email ↗

Utiliser un nouveau destinataire pour chaque cas

Créez la boîte InboxTap dans le test et saisissez inbox.address dans le véritable formulaire ou la véritable requête API de connexion. Le destinataire généré permet aux tests simultanés de partager un serveur de capture tout en filtrant chaque lecture sur leur propre enveloppe SMTP.

Évitez une boîte unique pour toute la suite et ne videz pas tous les messages dans beforeEach. Un nettoyage global crée des conflits entre les tests, tandis qu’une adresse unique conserve les éléments nécessaires au diagnostic d’une mauvaise redirection ou d’une livraison en double.

Extraire et valider avant de naviguer

waitForLink() recherche les liens HTTP ou HTTPS dans le texte et le HTML capturés et peut exiger un fragment de chemin stable. Les modèles contiennent souvent des URL d’assistance, de confidentialité, de logo et de désinscription : un filtre contains empêche donc le test de suivre le premier lien sans rapport.

Traitez la valeur renvoyée comme un identifiant secret. Analysez-la avec URL, comparez l’origine attendue complète, puis le chemin de rappel avant de naviguer. N’utilisez pas une vérification approximative du suffixe de l’hôte, n’affichez pas la chaîne de requête et ne placez pas le jeton dans le nom du test.

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

const url = new URL(rawUrl);
expect(url.origin).toBe(appOrigin);
expect(url.pathname).toBe("/auth/callback");

await page.goto(url.href);

Vérifier la session, et pas seulement la page

Après l’ouverture du lien, vérifiez l’URL finale et un indicateur de l’identité authentifiée provenant du serveur. Un message de réussite visible peut s’afficher alors que le cookie de session, l’identité de l’utilisateur ou les autorisations sont erronés.

Contrôlez aussi la redirection prévue et la validation éventuelle de l’adresse lorsque le fournisseur d’authentification associe la preuve de propriété à la vérification. Ces résultats relèvent de l’assertion applicative ; InboxTap prouve uniquement ce qui a franchi la frontière SMTP.

Couvrir la réutilisation, l’expiration et le mauvais destinataire

Utilisez la même URL une seconde fois et vérifiez le comportement à usage unique configuré. Exercez l’expiration avec l’horloge prise en charge par le fournisseur ou une courte durée propre au test, plutôt qu’avec une attente non bornée. Un jeton altéré ou mal formé doit échouer sans créer de session.

Si le produit lie un lien à un email ou à une transaction en attente, prouvez qu’il ne peut pas authentifier un autre compte. Échanger uniquement des adresses InboxTap ne suffit pas : réalisez l’assertion sur la session et l’identité stockée par l’application.

• Un lien valide établit uniquement le compte et la redirection attendus.
• Un jeton réutilisé, expiré ou modifié est rejeté.
• Les pages d’échec et les journaux n’affichent pas la valeur secrète.

Conserver des preuves sans jetons

Les diagnostics des assertions InboxTap n’incluent ni le corps des messages ni les URL porteuses de jetons. Les rapports masqués retirent les surfaces secrètes courantes et remplacent les adresses par des pseudonymes, mais ce masquage reste une protection au mieux. Relisez tout livrable avant de le partager hors de l’environnement de test.

Préférez des assertions sur l’origine et le chemin de l’URL, la présence d’un paramètre et l’état final de l’application. Évitez les instantanés de l’email brut, de la barre d’adresse ou du lien capturé complet lorsqu’une assertion structurelle plus petite prouve le même comportement.