lovable login stirbt nach dem Publish

Dein lovable login sah im Editor fertig aus — und war tot, sobald du auf Publish geklickt hast.

In der Vorschau fühlte sich alles solide an. Du hast auf Anmelden geklickt, einen Magic Link oder ein Google-Fenster bekommen und warst in der App. Nach dem Publish fällt derselbe Ablauf auseinander. Nutzer starren auf einen Login-Button, der nichts tut — oder sie melden sich an und landen wieder auf dem Startbildschirm.

Was du nach dem Publish siehst

Die Symptome gruppieren sich um wenige Muster. Welches bei dir zutrifft, spart Zeit bei der Fehlersuche.

Der Login-Button reagiert nicht

Du klickst auf Anmelden. Die Seite flackert kurz. Keine Fehlermeldung. Im Netzwerk-Tab siehst du eine Anfrage an Supabase — dann Stille. Manchmal zeigt der Button-Handler noch auf eine Umgebungsvariable, die nur in der Vorschau existiert. Manchmal ist die Redirect-URL ungültig und der Client bricht ab, bevor der Provider öffnet.

Magic Link bringt dich zurück zum Login

Du gibst deine E-Mail ein. Supabase schickt den Link. Du klickst. Der Browser lädt deine Seite — und setzt dich wieder auf den Login-Screen. Die Session bleibt nicht. In der Adresszeile blitzen kurz access_token-Fragmente auf, dann verschwinden sie ohne eingeloggten Nutzer.

Google-Anmeldung dreht sich im Kreis

Du wählst dein Google-Konto. Google bestätigt. Der Browser leitet weiter. Du landest wieder beim Login. Nochmal Google — dieselbe Schleife. Der OAuth-Handshake auf dem Server klappt, aber die finale Weiterleitung passt nicht zu einer URL, die Supabase für deine Live-Domain akzeptiert.

Passwort-Reset führt ins Leere

Die Reset-Mail kommt an. Der Link zeigt auf http://localhost:3000 oder einen alten Vorschau-Hostnamen. Nutzer klicken und bekommen einen Browserfehler — oder eine Seite, die nicht deine Produktions-App ist. Sie halten das Produkt für kaputt.

Callback zeigt noch localhost

Öffne das E-Mail-Template oder den OAuth-Fehler in den Supabase-Logs. Dort steht redirect_uri=http://localhost:5173/... oder eine Lovable-Vorschau-URL. Das ist der Beweis. Produktions-Traffic soll zurück zu einem Host, der nur beim Bauen existierte.

Diese Fehler treten oft zusammen auf. Einmal die URL-Konfiguration korrigieren, und mehrere Symptome verschwinden gleichzeitig. Für die breitere Publish-Checkliste siehe lovable deploy.

Warum die KI Site URL auf Vorschau oder localhost gesetzt hat

Lovable erzeugt Code gegen die Umgebung, die es sehen kann. Beim Bauen ist das die Vorschau-Origin. Supabase-Client, OAuth-Callbacks und E-Mail-Templates erben diese Origin — außer du überschreibst sie.

Die KI optimiert auf „Login soll hier und jetzt funktionieren.“ In der Vorschau sind localhost und die Lovable-Dev-URL gültige Ziele. Supabase bringt http://localhost:3000 als Standard mit. Der Agent kopiert das in redirectTo-Optionen und Env-Beispiele. Das ist Kontext-Blindheit, kein böser Wille.

Supabase kennt deine Produktions-Domain erst, wenn du sie einträgst. Ein Projekt in Lovable zu verbinden richtet Keys und Tabellen ein. Es schreibt Auth-URLs nicht um, wenn du publishst.

Google OAuth legt eine weitere Schicht drauf. Die KI registriert oft den Supabase-Callback für die Vorschau-Defaults. Wenn du auf yourapp.lovable.app oder eine Custom Domain gehst, aktualisiert sich nichts in der Kette von selbst.

Magic Links und Passwort-Resets nutzen dieselbe Site-URL. Steht dort noch localhost, schicken alle E-Mail-Links Nutzer zu localhost.

Vorschau und Produktion können auch auf verschiedene Supabase-Projekte zeigen, wenn Keys manuell kopiert wurden. Der Artikel supabase auth geht tiefer auf Vorschau-vs.-Live-Mismatches ein.

lovable login in Lovable und Supabase reparieren

Arbeite in dieser Reihenfolge. Einen Schritt überspringen, und die Schleife kommt zurück.

1. Publish und Live-URL kopieren. In Lovable das Projekt veröffentlichen, falls noch nicht geschehen. Die volle Origin kopieren: https://your-project.lovable.app oder deine Custom Domain mit https://. Kein trailing path, außer die App lebt wirklich in einem Unterordner.
2. Das richtige Supabase-Projekt öffnen. In Lovable prüfen, welches Supabase-Projekt verknüpft ist. Dasselbe Projekt im Supabase-Dashboard öffnen. Nutzen Vorschau und Live verschiedene Projekte, erst diesen Mismatch beheben.
3. Site URL setzen. In Supabase: Authentication → URL Configuration. Site URL auf deine Live-Origin setzen, z. B. https://your-project.lovable.app.
4. Redirect URLs ergänzen. Im selben Screen jede Origin eintragen, die Auth-Callbacks empfangen soll. Mindestens Live-URL, Lovable-Vorschau-URL und http://localhost:5173, falls du lokal testest. Explizite Callback-Pfade hinzufügen, z. B. https://your-project.lovable.app/auth/callback.
5. Google OAuth anpassen, falls genutzt. In der Google Cloud Console den OAuth-Client öffnen. Unter Authorized redirect URIs den Supabase-Callback eintragen: https://<project-ref>.supabase.co/auth/v1/callback. In Supabase unter Authentication → Providers → Google Client-ID und Secret mit dem Google-Projekt abgleichen.
6. redirectTo im Code prüfen. In Lovable nach redirectTo, emailRedirectTo und hardcodiertem localhost suchen. Feste localhost-Strings durch window.location.origin oder eine Env-Variable ersetzen, die in Produktion den aktuellen Host liefert.
7. Erneut publishen. Änderungen in Lovable speichern und nochmal publishen, damit das Live-Bundle Code-Fixes mitnimmt. URL-Änderungen in Supabase gelten sofort — Code mit localhost überschreibt sie aber.
8. In sauberer Session testen. Privates Browserfenster öffnen. Magic Link und Google je einmal durchspielen. Prüfen, dass du in der App landest, nicht wieder beim Login.

Nach einer URL-Änderung zeigen alte Magic Links in früheren E-Mails noch auf alte Hosts. Beim Testen einen frischen Link schicken.

Checkliste, bevor du lovable login als gefixt wertest

• Site URL in Supabase entspricht exakt deiner Live-Origin, inklusive https://.
• Redirect URLs listen Live, Vorschau und jede lokale Dev-Origin, die du noch nutzt.
• Kein localhost mehr in Passwort-Reset- oder Magic-Link-E-Mails aus Produktions-Flows.
• Google autorisierte Redirect-URIs enthalten den Supabase-/auth/v1/callback-Endpoint des aktiven Projekts.
• App-Code nutzt die aktuelle Origin für redirectTo, keinen hardcodierten Vorschau-Host.
• Lovable-Publish nach der letzten Auth-Code-Änderung abgeschlossen.
• Magic Link und Social Login im privaten Fenster auf der Live-URL getestet.
• Supabase Auth-Logs zeigen redirect_uri mit deiner Live-Domain, nicht localhost.

Wenn jede Box angehakt ist, sollte Login auf der Live-Seite genauso laufen wie in der Vorschau. Scheitert ein Provider noch, Redirect in den Logs Zeichen für Zeichen mit der Redirect-URLs-Liste vergleichen.

FAQ

Warum funktioniert lovable login in der Vorschau, aber nicht nach dem Publish?

Die Vorschau läuft auf einer Lovable-URL, die Supabase bereits kennt. Deine Live-Domain steht erst in Site URL und Redirect URLs, wenn du sie manuell einträgst. Auth-Anfragen prallen dann auf localhost oder werden abgelehnt.

Wo ändere ich die Supabase-Callback-URL für eine Lovable-App?

Öffne dein Supabase-Projekt, gehe zu Authentication, dann URL Configuration. Setze Site URL auf deine Live-Domain und trage jeden Redirect-Pfad unter Redirect URLs ein — Vorschau und Produktion.

Warum dreht Google-Login in einer Endlosschleife?

Google schickt Nutzer an die in Supabase registrierte Redirect-URI. Wenn dort noch localhost oder ein Vorschau-Host steht, landet die Session nie in der Live-App. Passe Redirect URLs und die autorisierten Redirect-URIs im Google-Cloud-OAuth-Client an.