supabase oauth schickt Nutzer nach dem Publish zurück auf localhost

Dein supabase oauth sah in der Vorschau fertig aus — und schickte Nutzer nach dem Publish auf localhost.

Du hast Mit Google anmelden geklickt. Die Zustimmungsseite kam. Du bestätigt. Der Browser leitete weiter — und öffnete einen toten localhost-Tab statt deiner Live-App. Kunden melden dieselbe Schleife in Produktion, während die Editor-Vorschau noch funktioniert. Der Provider ist nicht kaputt. Die Callback-URL-Kette zeigt noch auf einen Host, der nur auf deinem Laptop existierte.

OAuth-Callback zeigt noch localhost

Die Symptome gruppieren sich um wenige Muster. Erkenne deins, bevor du wahllos Einstellungen änderst.

Browser öffnet localhost nach Google oder GitHub

Der OAuth-Provider ist durch. In der Adresszeile steht http://localhost:3000 oder http://localhost:5173 mit Hash-Fragmenten. Die Seite lädt für Endnutzer nicht. Tokens blitzen kurz auf und verschwinden, weil in Produktion nichts auf diesem Port lauscht.

Redirect-URI-Mismatch-Fehler

Supabase oder der Provider zeigt redirect_uri_mismatch. Die URI im Fehler passt nicht zu dem, was du in der Google Cloud Console oder bei der GitHub-OAuth-App registriert hast. Oft stimmen Vorschau-URL und Live-URL nicht überein, weil du die Live-URL nie eingetragen hast.

Anmeldung nur in der Lovable-Vorschau

Im Editor kehrt OAuth zur Lovable-Vorschau-Origin zurück. Nach dem Publish schickt derselbe Button Nutzer auf localhost oder einen alten Vorschau-Hostnamen. Die Session landet nie auf yourapp.lovable.app oder deiner Custom Domain.

Supabase-Logs zeigen falsche redirect_uri

Öffne Authentication → Logs in Supabase. Fehlgeschlagene OAuth-Zeilen listen redirect_uri=http://localhost:.... Der Wert stammt aus Site URL, Redirect URLs oder hardcodiertem redirectTo im Client-Code.

Diese Fehler haben oft eine gemeinsame Ursache. URL Configuration einmal korrigieren — und Google-, GitHub- und Magic-Link-Flows verbessern sich zusammen. Für die breitere Publish-Checkliste siehe lovable deploy.

Warum die KI supabase oauth auf Vorschau-Hosts verdrahtet hat

Lovable erzeugt Auth-Code gegen die Umgebung, die es sehen kann. Beim Bauen ist das die Vorschau-Origin. Der Supabase-Client erbt Standard-Redirect-Ziele, außer du überschreibst sie.

Supabase bringt http://localhost:3000 oft als Site-URL-Default mit. KI-Assistenten kopieren das in signInWithOAuth-Optionen und Env-Beispiele, weil Login im Sandbox sofort funktionieren muss. Optimiert wird für „OAuth hier erfolgreich“, nicht für „OAuth auf einer Domain, die du noch nicht veröffentlicht hast“.

Supabase in Lovable zu verbinden verdrahtet API-Keys und Tabellen. Es schreibt die Authentication URL Configuration beim Publish nicht um. Google- und GitHub-OAuth-Apps brauchen explizite autorisierte Redirect-URIs. Die KI registriert den Supabase-Callback für die Projekt-Ref, aber der Rückweg in deine App hängt von Redirect URLs ab, die du pflegst.

OAuth ist eine Kette: deine App → Supabase → Provider → Supabase-Callback → deine App. Jeder Link, der noch auf localhost zeigt, bricht den letzten Hop für echte Nutzer. Magic Links und Passwort-Reset nutzen dieselbe Site-URL — localhost dort vergiftet auch E-Mail-Links.

Wenn Login-Symptome mit Magic Links überlappen, lies lovable login für die volle Redirect-Checkliste. OAuth-spezifische Fixes starten auf demselben URL-Configuration-Screen.

supabase oauth in Supabase und beim Provider fixen

In dieser Reihenfolge vorgehen. Einen Schritt überspringen — und der localhost-Redirect kommt zurück.

1. Publish und Live-Origin kopieren. In Lovable publishen, falls noch nicht geschehen. https://your-project.lovable.app oder Custom Domain mit https:// kopieren. Kein trailing slash, außer die App lebt wirklich in einem Unterpfad.
2. Richtiges Supabase-Projekt öffnen. Prüfen, welches Projekt Lovable verknüpft hat. Dasselbe Projekt im Supabase-Dashboard öffnen. Vorschau und Produktion sollen nicht unbeabsichtigt auf verschiedene Projekte zeigen.
3. Site URL setzen. Authentication → URL Configuration. Site URL auf deine Live-Origin setzen.
4. Redirect URLs ergänzen. Auf demselben Screen Live-URL, Lovable-Vorschau-URL und http://localhost:5173 eintragen, falls du lokal testest. Explizite Callback-Pfade wie https://your-project.lovable.app/auth/callback hinzufügen, wenn dein Router sie erwartet.
5. Google OAuth aktualisieren, falls genutzt. In der Google Cloud Console den OAuth-Client öffnen. Unter Authorized redirect URIs https://<project-ref>.supabase.co/auth/v1/callback listen. In Supabase unter Authentication → Providers → Google Client-ID und Secret prüfen.
6. GitHub OAuth aktualisieren, falls genutzt. Bei GitHub → Settings → Developer settings → OAuth Apps die Authorization callback URL auf dieselbe Supabase-Callback-URL setzen. GitHub-Provider in Supabase mit passender Client-ID und Secret aktivieren.
7. Hardcodiertes localhost im Code entfernen. In Lovable nach redirectTo, signInWithOAuth und literal localhost suchen. window.location.origin plus Callback-Pfad oder Env-Variable nutzen, die in Produktion auf den aktuellen Host zeigt.
8. Republishen und im privaten Fenster testen. Speichern, publishen, dann Google- und GitHub-Login jeweils einmal auf der Live-URL durchspielen. Bestätigen, dass du in der App landest — nicht auf Login oder localhost.

Alte OAuth-Sessions im Browser können Fixes maskieren. Nach jeder URL-Änderung mit frischem privatem Fenster testen.

Checkliste, bevor du supabase oauth als gefixt wertest

• Site URL entspricht der Live-Origin, nicht localhost
• Redirect URLs enthalten Live, Vorschau und jeden lokalen Dev-Origin, den du noch nutzt
• Google- oder GitHub-OAuth-App listet die Supabase-Callback-URI exakt
• Client-Code hardcodiert kein http://localhost für redirectTo
• Supabase-Logs zeigen erfolgreiches OAuth auf der Live-Domain
• Privates Fenster: Anmeldung in Produktion schließt ab

FAQ

Warum leitet supabase oauth nach dem Publish auf localhost um?

Supabase baut OAuth-Redirect-URIs aus Site URL und Redirect URLs unter Authentication. Vorschau- und Localhost-Hosts stehen standardmäßig drin. Deine Live-Domain fehlt, bis du sie manuell einträgst — dann schickt der Provider Nutzer zurück auf localhost.

Wo fixe ich die supabase oauth Callback-URL?

Supabase → Authentication → URL Configuration. Site URL auf deine Live-Origin setzen und jeden erlaubten Redirect-Pfad unter Redirect URLs eintragen — Vorschau und Produktion. Gleichen Callback in Google- oder GitHub-OAuth-App hinterlegen.

Braucht supabase oauth andere Einstellungen für Vorschau und Produktion?

Ja. Beide Origins unter Redirect URLs listen, damit lokal getestet werden kann und Live-Nutzer sich anmelden können. Code sollte window.location.origin oder env-basierte Redirects nutzen, nicht hardcodiertes localhost.