Lovable Login Redirect Loop: Prompts, um das Problem sicher zu beheben

Eine Login-Endlosschleife in Lovable löst man am besten, indem man den genauen Fehlerpunkt findet: Session-Erstellung, Callback-Handling, Route Protection oder der Zugriff auf Benutzerdaten. Lass Lovable diesen Pfad analysieren, bevor Code geändert wird, und gib anschließend nur einen eng umrissenen Patch frei. Diese Anleitung liefert Copy-Paste-Prompts, eine Test-Checkliste und ein Debugging-Budget, um unnötige Fehlversuche zu vermeiden.

Der Fokus ist hier entscheidend. Es geht um Apps, die zwischen Login und einer geschützten Seite hin- und herspringen oder direkt nach der Authentifizierung wieder beim Login landen. Eine fehlerhafte Bestätigungsmail, ein ausgefallener Identity Provider oder ein falsches Passwort erfordern andere Lösungswege.

Warum deine Lovable-App ständig zum Login zurückspringt

Ein Redirect-Loop ist ein Symptom, keine Diagnose. Wenn der Browser das Dashboard kurz anzeigt, beweist das noch lange nicht, dass die App die Session bereits vollständig wiederhergestellt hat.

Viele Auth-Flows benötigen mindestens drei Zustände:

• Loading: Die App weiß noch nicht, ob eine Session existiert.
• Authenticated: Eine gültige Session ist verfügbar.
• Unauthenticated: Die Prüfung ist abgeschlossen, es gibt keine nutzbare Session.

Behandelt ein Route Guard den Zustand "Loading" fälschlicherweise als "Unauthenticated", leitet er zu früh weiter. Das ist eine plausible Ursache, aber kein Allheilmittel. Ein Loading-Spinner repariert weder eine falsche Callback-URL noch eine abgewiesene Datenbankabfrage.

Ein anderes Fehlerbild sieht fast identisch aus: Die Authentifizierung klappt, doch die Profilabfrage scheitert. Die App deutet fehlende Profildaten als fehlende Session und schickt den Nutzer postwendend zurück zum Login. Diese Unterscheidung ist zentral, denn Änderungen am eigentlichen Auth-Code lassen das reale Problem dann unberührt.

Diese Tabelle hilft bei der ersten Bestandsaufnahme, ohne voreilig Schlüsse zu ziehen:

| Beobachtung | Zuerst prüfen | Nicht blind ändern | |---|---|---| | Refresh einer geschützten Seite führt zum Login | Session-Initialisierung und Timing der Route Guards | Den gesamten Auth-Provider | | Passwort-Login klappt, OAuth scheitert | Provider-Einstellungen, Callback-Handling, Redirect-Ziele | Logik des Passwort-Logins | | Preview funktioniert, veröffentlichte Domain scheitert | Umgebungskonfiguration und erlaubte Redirect-URLs | Datenbank-Berechtigungen | | Login klappt, danach scheitert Profilabfrage | Query-Fehler, Profilerstellung, Access Policies | Session-Persistenz | | Nur bestehende Browser-Sessions scheitern | Gespeicherter Session-Status und Refresh-Verhalten | Account-Daten aller Nutzer | | Login und Dashboard wechseln sich endlos ab | Konkurrierende Redirects und Auth-Subscriptions | Unbeteiligte Routes oder Seiten-Layouts |

Nutzt deine App Supabase für die Authentifizierung, gehören Session-Handling und Redirect-Konfiguration ganz oben auf die Prüfliste. Bei einem anderen Backend passt du die Prompts entsprechend an. Verlange von Lovable keinesfalls eine Provider-Migration als vermeintliche Abkürzung beim Debugging.

Die Grundregel: Untersuche die Schnittstelle, an der es hakt - nicht jede beliebige Komponente, die irgendwo einen User erwähnt.

Beweise sammeln, bevor Credits verpuffen

Nimm dir 10 bis 15 Minuten Zeit, um den Fehler sauber zu reproduzieren. Das ist eine realistische Schätzung und praktisch immer die bessere Investition als ein vages "Fix login" in den Prompt zu werfen.

1. Halte die exakte Umgebung fest. Dokumentiere, ob der Fehler in der Lovable-Preview, auf der veröffentlichten URL oder auf einer Custom Domain auftritt. Notiere Browser und Login-Methode. Tritt das Problem nur beim Google-Login auf der eigenen Domain auf, gehört genau das direkt in die Fehlerbeschreibung.

2. Formuliere die kürzeste Reproduktionsanleitung. Beispiel: `/dashboard` im abgemeldeten Browser aufrufen, Weiterleitung zu `/login`, korrekte Daten eingeben, `/dashboard` blitzt kurz auf, danach wieder `/login`. Verwende dabei die tatsächlichen Pfade deiner App.

3. Trenne neue von bestehenden Sessions. Teste das Verhalten in einem Inkognito-Fenster. Funktioniert es dort, deutet das auf ein Problem mit dem gespeicherten Session-Status hin - es beweist aber nicht, dass simples Löschen des Speichers eine dauerhafte Lösung ist. Behalte die fehlerhafte Session bei, bis du ihr Verhalten genau dokumentiert hast.

4. Suche den ersten relevanten Fehler. Öffne die Entwicklertools des Browsers und prüfe Konsole sowie Netzwerk-Tab. Aktiviere "Preserve log", falls verfügbar. Halte nach dem ersten fehlgeschlagenen Request Ausschau - sei es Callback, Auth oder Profilabfrage - statt dich am letzten Folgefehler der Kaskade festzubeißen.

Ein 401- oder 403-Statuscode liefert einen Hinweis, keine fertige Erklärung. Notiere Endpoint, Status und eine bereinigte Fehlermeldung. Kopiere niemals Passwörter, Cookies, Access Tokens, Refresh Tokens, Authorization-Header oder unbereinigte Netzwerk-Logs in einen Prompt.

5. Ermittle den letzten funktionierenden Stand. Welche Änderung kam zuletzt dazu: eine neue geschützte Route, eine Custom Domain, ein Onboarding-Schritt oder ein zusätzliches Profilfeld? Sichere dir eine funktionierende Code-Version über die Versionshistorie oder dein Repository. Bedenke: Ein Code-Rollback setzt Datenbank-Migrationen oder externe Auth-Settings nicht automatisch zurück.

Fülle anschließend dieses Briefing aus:

```text Bug: Login leitet wieder auf die Login-Seite weiter. Umgebung: [Preview / veröffentlichte URL / Custom Domain] Auth-Backend und Methode: [Backend; Passwort / OAuth / Magic Link] Erwartetes Ergebnis: [Zielseite und sichtbarer Zustand] Tatsächliche Route-Abfolge: [Pfad -> Pfad -> Pfad] Schritte zur Reproduktion: [nummerierte Schritte] Ergebnis im neuen Inkognito-Fenster: [Ergebnis] Ergebnis mit bestehender Browser-Session: [Ergebnis] Erster relevanter Fehler: [bereinigte Meldung und Request-Status] Letzter funktionierender Stand: [Version oder unbekannt] Kürzliche relevante Änderung: [Änderung oder unbekannt] ```

"Unbekannt" ist eine brauchbare Antwort. Eine erfundene Erklärung hilft niemandem.

Hänge diese Zusammenfassung an nachfolgende Prompts an. In unserer Prompt-Bibliothek findest du Vorlagen für andere Aufgaben, doch vermeide es strikt, eine Auth-Reparatur mit Redesigns oder neuen Feature-Wünschen zu vermischen.

Copy-Paste-Prompts für einen gezielten Auth-Fix

Nutze diese Prompts nacheinander. Sie dienen als Entscheidungsschritte, nicht als Paket, das man auf einmal abschickt. Wenn schon die erste Analyse zeigt, dass Daten auf dem Dashboard fehlen statt die Authentifizierung selbst zu scheitern, folge dieser Spur.

Prompt 1: Analysieren ohne Code-Änderungen

Starte mit einer reinen Analyseanfrage. Bietet deine Lovable-Oberfläche einen Planungs- oder Diskussionsmodus, nutze ihn, ziehe aber trotzdem klare Grenzen im Prompt. Ein Prompt ist kein technischer Schreibschutz, wirf also ein Auge auf die tatsächlichen Aktionen des Tools.

```text Untersuche diesen Login-Redirect-Loop. Ändere noch keine Dateien, Konfigurationen, Datenbank-Policies oder Schemas.

[HIER DAS AUSGEFÜLLTE FEHLER-BRIEFING EINFÜGEN]

Verfolge den Auth-Flow im aktuellen Projekt:

1. Wo die Session initialisiert und aktualisiert wird.
2. Wie sich Loading-, Authenticated- und Unauthenticated-Zustände unterscheiden.
3. Welche Guards und Effects Navigation auslösen.
4. Wie der Login-Callback abgeschlossen wird, falls zutreffend.
5. Ob Fehler bei Profilabfragen oder beim Onboarding einen Login-Redirect auslösen.

Nenne die relevanten Dateien und Funktionen. Priorisiere wahrscheinliche Ursachen anhand der vorliegenden Fakten. Trenne Beobachtungen klar von Hypothesen. Wenn du eine Runtime-Einstellung oder ein Log nicht einsehen kannst, sag das offen.

Schlage den kleinstmöglichen nächsten Diagnoseschritt vor. Stoppe vor der Umsetzung. ```

Eine brauchbare Antwort nennt konkrete Dateien, Bedingungen und fehlende Informationen. Ein pauschales "Die Authentifizierung ist falsch konfiguriert" reicht nicht aus. Genauso wenig ein Plan, das gesamte Auth-System auszutauschen, bevor man den Ablauf überhaupt nachvollzogen hat.

Prompt 2: Eine Unklarheit ausräumen

Diesen Prompt setzt du ein, wenn nach der Analyse zwei plausible Ursachen übrig bleiben. Ersetze die Angaben in den eckigen Klammern durch deine konkreten Punkte.

```text Wir müssen [Hypothese A] von [Hypothese B] unterscheiden. Nimm noch keinen dauerhaften Fix vor.

Schlage einen einzelnen Diagnoseschritt vor und erkläre, was die möglichen Ergebnisse bedeuten würden. Bevorzuge vorhandene Logs und Browser-Beobachtungen.

Falls temporäres Logging nötig ist, zeige das vorgeschlagene Diff zuerst zur Freigabe. Logge ausschließlich Statusnamen, Zeitstempel und Pfade. Logge niemals Tokens, Cookies, Zugangsdaten oder personenbezogene Profildaten. Verändere beim Messen nicht das Navigationsverhalten.

Füge eine Anleitung bei, wie der Diagnosecode wieder entfernt wird. ```

Das verhindert einen typischen Fehler: das Verhalten des Systems unabsichtlich zu verändern, während man noch herausfinden will, was vorher passiert ist. Der nächste Schritt wird dadurch spürbar präziser.

Prompt 3: Nur die bestätigte Ursache patchen

Sobald die Fakten eine Ursache stützen, gibst du eine eng begrenzte Umsetzung frei. Definiere die Grenzen anhand des Verhaltens, statt stur das Editieren von exakt einer Datei zu verlangen.

```text Setze einen minimalen Fix für diese belegte Ursache um: [URSACHE UND BELEGENDE HINWEISE]

Erlaubter Umfang: [relevante Dateien oder Subsystem]. Behalte das bestehende Auth-Backend, die Login-Methoden, Routes, das Layout und sonstiges Verhalten der Anwendung bei.

Deaktiviere keine Zugriffskontrollen, füge keine Dependencies hinzu, migriere kein Schema und refaktoriere keinen unbeteiligten Code. Erfordert der Fix weitergehende Änderungen, halte inne und erkläre die Gründe vorab.

Anforderungen:

• Leite nicht weiter, nur weil die Session-Initialisierung noch läuft.
• Trenne das Fehlen einer Session sauber von Fehlern beim Profil oder Onboarding.
• Behalte berechtigte Redirects für abgemeldete Nutzer und das Sign-out-Verhalten bei.
• Baue keine willkürlichen Timeouts ein, um Race Conditions zu kaschieren.

Liste nach den Änderungen alle modifizierten Dateien auf, erkläre die Verhaltensänderung und nenne tatsächlich durchgeführte Tests. Kennzeichne nicht ausgeführte Tests explizit. ```

Übernimm nur die Anforderungen, die zu deiner Diagnose passen. Liegt das verifizierte Problem an einer externen Callback-Einstellung, frag nach der exakten Konfigurationsanpassung und den Prüfschritten, statt krampfhaft einen Code-Patch zu erzwingen.

Ein willkürlicher Zwei-Sekunden-Timer kuriert Timing-Probleme nur oberflächlich. Auf dem schnellen Entwickler-Laptop kaschiert er den Bug vielleicht, bei einer langsameren Verbindung schlägt der Fehler sofort wieder durch.

Prompt 4: Auf Auth-Regressionen prüfen

Ein funktionierender Login ist notwendig - reicht als Erfolgsnachweis aber nicht aus.

```text Prüfe den Auth-Fix im Vergleich zur vorherigen Version. Nimm während dieses Reviews keine weiteren Änderungen vor.

Prüfe folgende Punkte:

• Geschützte Inhalte werden im abgemeldeten Zustand zugänglich.
• Redirects passieren, bevor die Session-Initialisierung abgeschlossen ist.
• Mehrfache Subscriptions oder konkurrierende Navigations-Effects.
• Profilfehler werden fälschlicherweise als fehlende Session interpretiert.
• Fehlerhaftes Verhalten bei Sign-out, Direktlinks oder Page-Refresh.
• Temporärer Logging-Code oder Secrets verbleiben im Code.

Trenne verifizierte Ergebnisse, Erkenntnisse aus dem Code-Review und Tests, die noch manuell ausgeführt werden müssen. Falls automatisierte Tests existieren, führe relevante Tests nach Möglichkeit aus und gib die echten Outputs an. ```

Gib dich nicht mit einem pauschalen "Alle Tests bestanden" zufrieden, ohne zu wissen, welche Tests überhaupt liefen. Eine reine Code-Prüfung kann die Live-Konfiguration eines OAuth-Providers nicht verifizieren, solange diese Einstellungen nicht tatsächlich geprüft wurden.

Den Fix verifizieren und ein Debugging-Budget festlegen

Plane 15 bis 25 Minuten für die Diagnose ein, 10 bis 20 Minuten für einen fokussierten Patch und 15 bis 25 Minuten für die Verifikation. Das ergibt ein Zeitfenster von 40 bis 70 Minuten für ein isoliertes Problem, keine Service-Garantie. Provider-Ausfälle, E-Mail-Zustellung oder Reparaturen an der Datenbank dauern oft länger.

Gehe diese Checkliste sowohl in der Preview-Umgebung als auch in der Produktivanwendung durch:

• [ ] Abgemeldete Besucher können keine geschützten Seiten aufrufen.
• [ ] Erfolgreicher Login landet ohne Bouncing auf der gewünschten Zielseite.
• [ ] Der Refresh einer geschützten Seite behält die gültige Session bei.
• [ ] Das direkte Aufrufen einer geschützten URL funktioniert für eingeloggte Nutzer.
• [ ] Sign-out sperrt den Zugriff auf geschützte Inhalte zuverlässig.
• [ ] Ungültige Zugangsdaten erzeugen eine verständliche Fehlermeldung statt einer Schleife.
• [ ] Jede unterstützte Login-Methode wurde separat getestet.
• [ ] Fehlende oder unzugängliche Profildaten werden sauber abgefangen.
• [ ] Temporärer Diagnosecode ist entfernt und das Diff enthält keine unbeteiligten Änderungen.

Teste mit Wegwerf-Accounts. Weiche niemals Zugriffskontrollen in der Production auf, nur um einen grünen Test zu erzwingen.

Setze dir ein klares Limit für den Credit-Verbrauch: eine Analyse, bei Bedarf ein abgrenzender Test, ein Patch und ein Review. Das meint vier klar umrissene Anfragen, kein Versprechen über exakt vier verbrauchte Credits. Der tatsächliche Verbrauch hängt von Lovables aktuellem Abrechnungsmodell und dem Arbeitsaufwand ab.

Behalte die Anzeige in deinem Account vor und nach dem Versuch im Blick. Ein Rechenbeispiel zur Orientierung: Lägen die effektiven Kosten bei 0,20 Dollar pro Credit und der Versuch verbraucht 10 Credits, entspricht das 2 Dollar. Diese Zahlen dienen nur der Veranschaulichung, nicht als Preisgarantie von Lovable. Wirf einen Blick in den Lovable Pricing Guide und in deinen Account, um echte Beträge zu ermitteln.

Haben zwei Patches am Verhalten nichts geändert, stoppe die Bearbeitung. Geh zurück zur Diagnose oder stelle den letzten funktionierenden Code-Stand wieder her - getrennt von Konfigurations- und Datenbankänderungen. Ein weiterer vager Prompt bringt dich nicht weiter.

Dokumentiere Reproduktion, Ursache, finales Diff und Testergebnisse. So ein kurzes Protokoll nützt dir künftig weit mehr als ein erleichtertes "Fixed!". Unsere Artikel zu Build und Operations beleuchten den restlichen Release-Workflow.

Warum funktioniert der Login in der Preview, aber nicht auf meiner Domain?

Die Umgebungen nutzen oft unterschiedliche Origins, Redirect-Ziele oder Backend-Konfigurationen. Gleiche die fehlerhafte Callback-URL und die Auth-Einstellungen mit der exakten Live-URL ab. Prüfe provider-spezifische Vorgaben, statt anzunehmen, ein Erfolg in der Preview beweise automatisch ein korrektes Production-Setup.

Sollte ich Row-Level Security deaktivieren, um den Login zu reparieren?

Nein. Nutzt dein Backend Row-Level Security, legt ein Abschalten sensible Daten offen, ohne das Authentifizierungsproblem wirklich zu lösen. Prüfe stattdessen zuerst, ob die Session existiert und welche Query genau fehlschlägt. Korrigiere die spezifische Abfrage, den Profilerstellungs-Flow oder die Access Policy, während die Autorisierungsgrenzen intakt bleiben.

Wie viele Lovable-Credits kostet ein Auth-Fix?

Dafür gibt es keinen verlässlichen Pauschalwert. Kontrolliere deinen tatsächlichen Verbrauch im Account und halte jede Anfrage eng umrissen. Ein präzises Fehler-Briefing und ein zielgerichteter Patch reduzieren unnötige Runden deutlich, garantieren aber weder eine fixe Credit-Zahl noch den Erfolg beim ersten Anlauf.