Tester les e-mails d'authentification des applications que vous créez avec Cursor

Pourquoi le parcours e-mail nécessite une vraie vérification

L’agent de Cursor est bon pour le code autour de l’authentification : formulaires, routes, gestion des jetons et modèles d’e-mail. Mais une modification peut réussir tous les tests et quand même envoyer un e-mail qui pointe vers localhost, qui n’arrive jamais parce que l’expéditeur n’est pas configuré, ou qui contient un code expirant avant qu’on ait pu le saisir. Ces problèmes n’apparaissent que lorsqu’un vrai e-mail atteint une vraie boîte de réception.

Quelle connexion va-t-il créer ?

Celui que vous demandez, ou celui que votre base de code utilise déjà. Supabase Auth, Clerk, Firebase Authentication, Auth.js et Better Auth envoient chacun des e-mails différents : Clerk envoie un code par défaut, Firebase un lien, et Auth.js uniquement des liens magiques sauf si vous construisez le reste. Nommez les méthodes voulues dans votre prompt ou votre règle de projet, puis testez chaque e-mail envoyé par la modification de l’agent. Les e-mails envoyés par chaque service de connexion.

Vérifiez après chaque modification de l’authentification

1. Exécutez l’application en local, ou ouvrez le déploiement de prévisualisation de votre branche.
2. Créez une adresse dans Proxy Mail QA, une par scénario : nouvel utilisateur, utilisateur invité, réinitialisation du mot de passe.
3. Suivez le parcours touché par la modification, avec le code ou le lien de la ligne de l’adresse.
4. Lisez l’e-mail en entier une fois dans la vue de la boîte de réception : expéditeur, objet, texte et chaque lien.
5. Notez ce que vous avez trouvé sur l’adresse, pour que cela reste avec le compte de test.

Les liens vers localhost sur un déploiement de prévisualisation ou de staging sont signalés sur la ligne. Voici comment les corriger dans Supabase, Firebase, Auth.js et d’autres stacks.

Laissez l’agent de Cursor vérifier l’e-mail lui-même

Ajoutez Proxy Mail QA depuis le Cursor Directory : Add to Cursor installe le MCP server et un skill qui guide l’agent dans un test d’inscription. Connectez-vous-y ensuite depuis la section MCP des paramètres de Cursor : vous vous connectez à Proxy Mail QA dans votre navigateur et choisissez un projet, sans clé d’API à copier.

Demandez ensuite en langage courant : « Inscris-toi sur localhost:3000 avec une nouvelle adresse Proxy Mail QA et confirme l’e-mail. » L’agent crée l’adresse, remplit votre formulaire, attend le code ou le lien et termine l’inscription. Pour utiliser plutôt une clé d’API dans .cursor/mcp.json, consultez Configuration de MCP server.

Prompts à copier-coller pour Cursor

List every email this app sends: sign-up confirmation, magic link, password reset, invite and email change. For each, show where it's triggered in the code, which service sends it, how its link URL is built, and how long its code or link is valid. Flag hard-coded localhost URLs.

Build every link in auth emails from an environment variable for the app's public URL, with localhost only as the development default. Add the variable to .env.example and the deployment settings.

The email says the code is valid for 10 minutes. Make the server enforce the same expiry, and make requesting a new code invalidate the old one.

Une règle de projet qui évite les bugs habituels

Enregistrez ceci comme règle de projet (par exemple .cursor/rules/auth-emails.mdc) pour que l’agent la suive chaque fois qu’il touche à l’authentification :

When changing sign-up, login, password reset, invites or any email-sending code:
- Build links from the app's public URL setting, never a hard-coded localhost.
- Keep the expiry stated in an email equal to the one the server enforces.
- Make single-use links and codes stop working once used or replaced.
- Tell me which emails to test by hand after the change.