Auth-E-Mails in Apps testen, die du mit Cursor baust

Warum der E-Mail-Weg eine echte Prüfung braucht

Der Agent von Cursor ist gut im Code rund um die Authentifizierung: Formulare, Routen, Token-Verarbeitung und E-Mail-Templates. Doch eine Änderung kann jeden Test bestehen und trotzdem eine E-Mail senden, die auf localhost verlinkt, nie ankommt, weil der Absender nicht eingerichtet ist, oder einen Code enthält, der abläuft, bevor ihn jemand eintippen kann. Das zeigt sich erst, wenn eine echte E-Mail einen echten Posteingang erreicht.

Welches Login wird er bauen?

Den, den du verlangst, oder den, den deine Codebasis schon nutzt. Supabase Auth, Clerk, Firebase Authentication, Auth.js und Better Auth senden jeweils andere E-Mails: Clerk sendet standardmäßig einen Code, Firebase einen Link und Auth.js nur Magic Links, wenn du den Rest nicht selbst baust. Nenne die gewünschten Methoden in deinem Prompt oder deiner Projektregel und teste dann jede E-Mail, die die Änderung des Agenten sendet. Welche E-Mails jeder Login-Dienst sendet.

Nach jeder Auth-Änderung prüfen

1. Starte die App lokal, oder öffne das Preview-Deployment für deinen Branch.
2. Erstelle eine Adresse in Proxy Mail QA, eine pro Szenario: neuer Nutzer, eingeladener Nutzer, Passwort-Reset.
3. Geh den Ablauf durch, den die Änderung betrifft, mit dem Code oder Link aus der Zeile der Adresse.
4. Lies die ganze E-Mail einmal in der Posteingangsansicht: Absender, Betreff, Wortlaut und jeden Link.
5. Notiere deine Erkenntnisse an der Adresse, damit sie beim Testkonto bleiben.

Links auf localhost in einem Preview- oder Staging-Deployment werden in der Zeile markiert. So behebst du sie in Supabase, Firebase, Auth.js und anderen Stacks.

Lass den Agenten von Cursor die E-Mail selbst prüfen

Füge Proxy Mail QA aus dem Cursor Directory hinzu: Add to Cursor installiert den MCP server und einen Skill, der den Agenten durch einen Registrierungstest führt. Melde dich dann im Bereich MCP der Cursor-Einstellungen an: Du meldest dich in deinem Browser bei Proxy Mail QA an und wählst ein Projekt, ohne einen API-Schlüssel zu kopieren.

Frag dann in einfachen Worten: „Registriere dich auf localhost:3000 mit einer neuen Proxy Mail QA-Adresse und bestätige die E-Mail.“ Der Agent erstellt die Adresse, füllt dein Formular aus, wartet auf den Code oder Link und schließt die Registrierung ab. Um stattdessen einen API-Schlüssel in .cursor/mcp.json zu nutzen, siehe MCP server-Einrichtung.

Prompts zum Kopieren für 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.

Eine Projektregel, die die üblichen Bugs verhindert

Speichere dies als Projektregel (zum Beispiel .cursor/rules/auth-emails.mdc), damit der Agent sie befolgt, wann immer er Auth anfasst:

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.