MELLEPRISE MELLEPRISE MP Blog
← Alle Artikel

replit auth sah fertig aus und bricht nach dem Deploy

Anmeldung & Login 4 Min. Lesezeit

Pastell-Comic einer Holztür, die allein auf einer Wiese steht, ohne Wand drumherum

Dein replit auth sah im Repl fertig aus — und fiel auseinander, sobald jemand den deployed Link öffnete.

Du hast den Agent gebeten, Google-Login hinzuzufügen. Er hat Routen, Session-Store und Anmelde-Button gebaut. Im Editor hast du durchgeklickt und ein Dashboard gesehen. Du deployed. Freunde öffneten die URL, klickten Anmelden — Fehler, weiße Seite oder Endlosschleife. Repl-Vorschau und öffentliches Deployment sind nicht dieselbe Runtime. Auth, das nur den Sandbox-Hostnamen kannte, schafft es nicht nach draußen.

Gebaut, unsicher, kaputt

Replit-Agent-Auth bringt oft drei Probleme mit: funktioniert nur im Repl, Secrets liegen am falschen Ort, Produktions-Callbacks sind falsch konfiguriert.

Anmelde-Button tut auf der deployed URL nichts

Der Click-Handler feuert im Repl, weil dort Umgebungsvariablen existieren. Auf dem deployed Host fehlen SESSION_SECRET oder OAuth-Client-IDs. Server-Routen liefern 500. Der Browser zeigt einen Spinner — dann nichts.

OAuth leitet auf den falschen Host um

Google oder GitHub schickt Nutzer zurück auf eine Repl-Dev-URL oder localhost. Der Provider hat diesen Callback beim Bauen registriert. Deployed Traffic passt nicht — die Session hängt nie an.

Sessions verschwinden beim Reload

Einmal eingeloggt. Seite neu laden — wieder ausgeloggt. Cookie-secure-Flags, Domain-Attribute oder In-Memory-Session-Stores verhalten sich in Vorschau und Deployment unterschiedlich. Der Agent wählte den einfachsten Weg für den Editor, nicht für HTTPS-Produktion.

Secrets sichtbar im Client-Code

Im generierten Bundle nach client_secret oder langen Zufallsstrings in Frontend-Dateien suchen. Stehen sie in React oder statischem JS, kann jeder sie extrahieren. Das ist kein Auth. Das ist ein öffentliches Passwort.

Diese Muster ähneln dem, was Lovable- und Bolt-Nutzer nach dem Publish sehen. Die Fix-Reihenfolge ist ähnlich, auch wenn der Editor anders ist. Vergleiche mit lovable login und dem Publish-Hub unter lovable deploy.

Warum der Agent replit auth so ausgeliefert hat

Replit Agent optimiert für „Login funktioniert jetzt in diesem Repl“. Er sieht den aktuellen Hostnamen, verfügbare Secrets und einen Einzelnutzer-Testflow. Er konfiguriert OAuth nicht automatisch für eine Deployment-URL, die du noch nicht erstellt hast.

Session-Bibliotheken starten im Development-Modus: Cookies ohne secure, Secrets aus .env-Dateien, die Deploy-Pipelines ignorieren, Redirect-URIs aus Doku-Beispielen mit localhost.

Agents packen Auth auch in eine Datei, um schneller zu shippen. Serverseitige Validierung, CSRF-Schutz und Refresh-Token-Rotation fallen weg, weil sie in einer Demo unsichtbar sind. Du siehst einen grünen Haken im Repl. Fehlende Produktions-Env-Vars siehst du erst, wenn ein echter Nutzer es versucht.

Replit Deployments nutzen anderen Hostnamen und Secret-Scope als die Editor-Vorschau. Ohne Secrets in die Deployment-Konfiguration zu kopieren und Provider-Callbacks zu aktualisieren, glaubt Auth-Code noch, er läuft auf der Build-Maschine.

Diese Schritte auf der deployed URL durchgehen — nicht nur in der Repl-Vorschau.

  1. Deployed Origin kopieren. Live-Deployment-URL öffnen. Volle https://-Origin kopieren, ohne trailing path, außer die App braucht einen.
  2. Secrets im Repl prüfen. Secrets in der Repl-Sidebar öffnen. Jeden Key listen, den Auth-Code liest: SESSION_SECRET, GOOGLE_CLIENT_ID, GOOGLE_CLIENT_SECRET, Datenbank-URLs, JWT-Signing-Keys. Gleiche Namen müssen für Deployment existieren — nicht nur für die Editor-Runtime.
  3. Fehlende Deployment-Secrets ergänzen. In Replit-Deployment-Einstellungen jedes Secret mit Produktionswerten hinzufügen. Frisches SESSION_SECRET erzeugen, wenn der Agent einen Platzhalter wiederverwendet hat. Demo-Secrets aus Tutorials nicht recyceln.
  4. OAuth-Provider-Callbacks aktualisieren. In Google Cloud Console oder GitHub-OAuth Redirect-URIs eintragen, die zur deployed Domain und Auth-Route passen, z. B. https://your-app.replit.app/auth/callback. Veraltete localhost-Einträge erst entfernen, wenn Produktion läuft.
  5. Cookie-Einstellungen für HTTPS fixen. In der Server-Auth-Config secure: true und sinnvolle sameSite-Policy für Produktion setzen. Session-Cookies müssen auf den deployed Hostnamen zielen, nicht auf localhost.
  6. Secrets aus dem Client raus. Frontend-Dateien nach API-Secrets durchsuchen. Token-Exchange und Session-Erstellung in Server-Routen legen. Der Browser soll nur Session-Cookies oder kurzlebige öffentliche Tokens bekommen.
  7. Redeployen und privat testen. Nach Secret- und Callback-Änderungen frisches Deployment triggern. Privates Browserfenster, einmal anmelden, reloaden — Session muss bleiben.
  8. Generierten Auth-Code reviewen. Login- und Callback-Handler des Agents Zeile für Zeile lesen. Ungenutzte Provider löschen, offene Routen schließen, einfaches Rate-Limiting auf Sign-in-Endpunkte setzen.

Kurz notieren, welche Secrets und Callbacks du geändert hast. Agents können Dateien neu generieren und manuelle Fixes überschreiben, wenn du das Auth-Modul nicht festnagelst.

Checkliste, bevor du replit auth produktionsreif nennst

  • Jedes Auth-Secret existiert in Deployment Secrets, nicht nur im Repl-Editor
  • OAuth-Redirect-URIs passen zur deployed https://-Origin
  • Keine Client-Secrets in Frontend-Bundles oder öffentlichen Repos
  • Session-Cookies nutzen secure auf der Live-Site
  • Anmeldung überlebt einen vollen Page-Reload im privaten Fenster
  • Provider-Dashboards listen nur Callbacks, die du noch kontrollierst

FAQ

Warum funktioniert replit auth im Repl, aber nicht nach dem Deploy?

Das Repl läuft mit Development-Secrets und bekannter Hostname. Deployed Apps nutzen andere Umgebungsvariablen und eine öffentliche URL. Session-Cookies, OAuth-Callbacks und JWT-Secrets, die nur im Repl existierten, brechen, sobald Traffic in Produktion geht.

Wo setze ich Secrets für replit auth in Produktion?

Repl öffnen, zu Secrets gehen und jeden Auth-Key in die Deployment-Umgebung kopieren. SESSION_SECRET, OAuth-Client-IDs und Callback-URLs auf die deployed Domain setzen — nicht localhost oder den Repl-Vorschau-Host.

Ist replit auth sicher, wenn der Agent es generiert hat?

Nur nach Review. Agents überspringen oft HTTPS-only-Cookies, kurze Session-Laufzeit und serverseitige Token-Speicherung. Generiertes Auth als Entwurf behandeln: Redirects prüfen, Secrets rotieren, Keys nie ins öffentliche Repo committen.