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

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

L’agent de Qoder 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 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 développez le reste. Indiquez les méthodes souhaitées dans votre demande, puis testez chaque e-mail envoyé par la modification de l’agent. Quels e-mails envoie 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.

Connectez-le depuis la Qoder Marketplace

Proxy Mail QA figure deux fois dans la Qoder Marketplace. Choisissez-en un :

• Le connecteur est le MCP server seul. Ouvrez Proxy Mail QA dans l’onglet Connectors de la Marketplace, sur le site international ou le site chinois, et connectez-le.
• Le plugin ajoute huit skills qui guident l’agent de Qoder tout au long de la tâche.

Connectez-vous ensuite à Proxy Mail QA dans votre navigateur quand Qoder le demande, en choisissant le projet que l’agent peut utiliser. En Chine continentale, connectez-vous avec votre e-mail : la connexion Google n’y est pas disponible.

Les skills du plugin :

• proxymail-qa : tester de bout en bout une inscription, une connexion ou une réinitialisation de mot de passe, avec le code ou le lien du vrai e-mail
• auth-regression-pack : les mêmes vérifications des e-mails d’inscription, de réinitialisation et d’invitation à chaque fois, avec ce qui a changé depuis la dernière exécution
• account-email-audit : déclencher chaque e-mail de compte envoyé par l’app et lister ce qu’il faut corriger
• signup-form-email-validation : vérifier que le formulaire accepte les adresses inhabituelles mais valides et refuse les adresses invalides
• age-and-region-testing : des comptes d’un âge et d’un pays donnés, pour les contrôles d’âge et le contenu régional
• email-delivery-troubleshooting : comprendre pourquoi un e-mail de test n’est pas arrivé
• mobile-sign-up-testing : s’inscrire dans une app iOS ou Android dans un simulateur ou un émulateur
• marketing-email-testing : coupons de bienvenue et paiement, une offre par personne, désinscription et règles de consentement par pays, avec les e-mails marketing et d’offres activés dans Labs

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

Pour ajouter plutôt le MCP server à la main, ouvrez Qoder IDE Settings, choisissez MCP, puis + Add dans l’onglet My Servers, et ajoutez-le sous mcpServers :

{
  "mcpServers": {
    "proxymail-qa": {
      "type": "http",
      "url": "https://api.proxymail.qa/mcp"
    }
  }
}

Enregistrez, puis connectez-vous à Proxy Mail QA dans votre navigateur quand on vous le demande, en choisissant le projet que l’agent peut utiliser. Réglez le niveau d’autorisation de Qoder sur Ask every time, et non Auto approve, et approuvez chaque étape Proxy Mail QA quand Qoder le demande : en Auto approve, l’agent peut ne pas trouver les outils et proposer la marketplace à la place. Demandez ensuite simplement : « 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. Les autres façons de se connecter, dont un clé d’API, sont dans Configuration de MCP server.

Prompts à copier-coller pour Qoder

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 qui évite les bugs habituels

Donnez cette règle à l’agent, dans les règles de votre projet ou au début d’une tâche d’authentification, pour qu’il 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.