supabase auth sieht in der Vorschau perfekt aus — dann treffen Nutzer nach dem Publish auf einen leeren Screen, einen Redirect-Fehler oder landen wieder auf der Login-Seite.
Du klickst Google oder GitHub, gibst ein Passwort ein oder tippst einen Magic Link an. Im Lovable-Editor endet der Flow und die App lädt. Auf deiner Live-URL hängt derselbe Button, zeigt redirect_uri_mismatch oder schickt Leute zu localhost. Die Session bleibt nicht. Deine Datenbank bleibt ohne eingeloggte Nutzer — obwohl der UI-Code unverändert ist.
Das ist kein Zufallsbug in deinen React-Komponenten. Supabase prüft jeden Login gegen eine Whitelist von URLs. Vorschau nutzt einen Hostnamen. Produktion einen anderen. Zeigt das Dashboard noch auf Dev-Defaults, scheitert Live-Traffic jedes Mal.
Warum supabase auth in der Vorschau klappt und live nicht
Lovable, Bolt, Replit und ähnliche Tools laufen beim Bauen auf einem Vorschau-Hostnamen. Supabase bringt oft http://localhost:3000 oder die Preview-Domain der Tool schon mit. Auth klappt dort, weil die Callback-URL passt.
Nach dem Publish lädt der Browser https://your-app.lovable.app oder eine Custom Domain. Supabase bekommt einen Callback von diesem Hostnamen. Steht Site URL noch auf localhost, oder fehlt der Live-Pfad in Redirect URLs, blockiert Supabase den Austausch. Der Nutzer sieht eine Fehlerseite oder wird ohne Session-Cookie zum Login geschickt.
Der KI-Assistent hat signInWithOAuth oder E-Mail-Magic-Links im Code korrekt verdrahtet. Selten öffnet er das Supabase-Dashboard, um deine Produktions-Domain einzutragen. Code kann URL-Konfiguration nicht überschreiben. Genau diese Lücke lässt Vorschau und Live auseinanderlaufen.
Ähnliche Symptome, wenn Lovable login nach Deploy bricht. Der Fix sitzt in Dashboard-Einstellungen, nicht in einem weiteren Prompt zum Auth-Hook.
Site URL auf deine Produktions-Domain setzen
Site URL sagt Supabase, welche Origin deiner App gehört. Magic Links, Passwort-Recovery-Mails und einige OAuth-Fallbacks nutzen sie als Standard-Rückkehrziel. Bleibt sie auf localhost, bekommen Produktionsnutzer Links, die auf deinen Laptop zeigen.
Supabase-Projekt öffnen. Authentication → URL configuration. Site URL finden. localhost-Wert durch deine Live-Origin ersetzen, inklusive https:// und ohne trailing slash, außer die App braucht ihn.
Beispiele:
https://your-app.lovable.appfür den Standard-Lovable-Hostnamenhttps://app.yourdomain.comnach Anbindung einer Custom Domain
Speichern. Site URL allein repariert nicht jeden OAuth-Flow — falsche Site URL bricht aber E-Mail-Links und erschwert Debugging, wenn Callbacks woanders stimmen.
Redirect URLs für Vorschau und Produktion ergänzen
Redirect URLs sind die explizite Liste von Pfaden, zu denen Supabase Nutzer nach dem Login zurückschicken darf. OAuth-Provider und PKCE-Flows vergleichen die volle Callback-URL mit dieser Liste. Fehlt ein Eintrag, scheitert Live sofort — auch wenn Site URL stimmt.
Im selben Screen URL configuration zu Redirect URLs scrollen. Jede Origin eintragen, die deine App nutzt:
- Deine Lovable-Vorschau-URL, falls du dort noch testest
- Deine veröffentlichte
*.lovable.app-URL - Deine Custom Domain, falls konfiguriert
- Wildcard nur, wenn du den Sicherheits-Tradeoff verstehst — explizite URLs sind sicherer
Pfad-Varianten einbeziehen, die dein Stack nutzt, z. B. /auth/callback oder / — passend zu redirectTo im generierten Client. Nach dem Hinzufügen Save. Login auf Produktion im privaten Fenster testen, damit alte Cookies das Ergebnis nicht verfälschen.
Redirect-URL-Fehler gehören zu den fünf Produktionseinstellungen, die Editoren überspringen. Die Lovable deploy-Checkliste bündelt sie mit Env-Vars und Webhooks, damit nichts halb konfiguriert shipped.
Google- und GitHub-Provider-Callbacks reparieren
Social Login bringt eine zweite Whitelist außerhalb von Supabase. Google Cloud und GitHub speichern jeweils autorisierte Redirect-URIs. Supabase schickt Nutzer zum Provider, der Provider muss sie zurück an eine Supabase-Callback-URL schicken, die du auf beiden Seiten registriert hast.
In Supabase Authentication → Providers. Google oder GitHub aktivieren, falls die KI sie im Code toggelt, im Dashboard aber aus lässt. Die Callback-URL kopieren, die Supabase für den Provider zeigt. Sie sieht aus wie https://<project-ref>.supabase.co/auth/v1/callback.
Für Google:
- Google Cloud Console → APIs & Services → Credentials
- OAuth 2.0 Client ID bearbeiten
- Unter Authorized redirect URIs die Supabase-Callback-URL exakt eintragen
- Speichern und ein paar Minuten auf Propagation warten
Für GitHub:
- GitHub → Settings → Developer settings → OAuth Apps
- App bearbeiten
- Authorization callback URL auf dieselbe Supabase-Callback-URL setzen
- Speichern
Zurück in Supabase Client-ID und Secret von Google oder GitHub ins Provider-Formular. Nochmal speichern. Mismatch zwischen Provider-Konsole und Supabase ergibt redirect_uri_mismatch im Browser — keinen hilfreichen Stacktrace in der App.
Klickpfad-Fix im Supabase-Dashboard
Diese Sequenz einmal pro Umgebungswechsel durchgehen. Reihenfolge zählt beim Debuggen eines frischen Publish.
- Supabase-Projekt → Authentication → URL configuration
- Site URL auf Produktions-Origin setzen
- Alle Vorschau- und Produktions-URLs unter Redirect URLs eintragen
- URL-Konfiguration speichern
- Authentication → Providers → Google oder GitHub
- Supabase-Callback-URL in Google Cloud oder GitHub-OAuth-Einstellungen kopieren
- Client-ID und Secret in Supabase einfügen → Provider speichern
- Live-App hart neu laden und Anmeldung im privaten Fenster testen
Scheitern Magic Links noch, E-Mail-Link auf demselben Gerät öffnen und prüfen, ob der Link-Host zur Site URL passt. Scheitert OAuth noch, Browser-Fehler-URL-Parameter Zeichen für Zeichen mit der Redirect-Liste vergleichen.
Produktions-Checkliste, bevor du den Code beschuldigst
- Site URL entspricht der Domain, die Nutzer in Produktion wirklich besuchen
- Redirect URLs enthalten Vorschau, Standard-Publish-Host und Custom Domain
- Callback-Pfade passen zu
redirectToin deinen Auth-Aufrufen - Google und GitHub autorisierte Redirect-URIs enthalten den Supabase-Callback
- Provider in Supabase aktiv mit korrekter Client-ID und Secret
NEXT_PUBLIC_SUPABASE_URLund Anon-Key in Produktions-Env passen zum selben Supabase-Projekt- Nach jeder Dashboard-Änderung im privaten Fenster getestet
Ist jede Box angehakt, verhält sich supabase auth in Vorschau und Live gleich. Ist eine URL falsch, repariert keine Menge KI-Refactors die Session.
FAQ
Warum funktioniert supabase auth in der Vorschau, aber nicht nach dem Publish?
Die Vorschau läuft auf einer URL, die Supabase bereits erlaubt. Produktion nutzt einen anderen Hostnamen, der in Site URL oder Redirect URLs fehlt — der Callback wird abgelehnt.
Was ist der Unterschied zwischen Site URL und Redirect URLs in Supabase?
Site URL ist die Standard-Origin, die Supabase für deine App erwartet. Redirect URLs sind die exakten Callback-Pfade, zu denen OAuth und Magic Links zurückkehren dürfen. Beides muss Produktion enthalten.
Muss ich Google und GitHub anpassen, wenn ich eine Custom Domain hinzufüge?
Ja. Jeder Provider speichert eigene autorisierte Redirect-URIs. Trage deine Produktions-Supabase-Callback-URL in Google Cloud Console und GitHub-OAuth-App-Einstellungen ein.
