KrostyMall/Landing-SENSORITY

Auth

Diese App betreibt ihre eigene Better Auth-Instanz unter /api/auth/* und föderiert über das genericOAuth-Plugin an den gemeinsamen Grok-Auth-Broker (auth.grok.me). Diese Vorlage verdrahtet Google und X.

Unterstützte Anmeldemethoden – verwende NUR diese drei; nichts anderes wird unterstützt: Google, X und E-Mail/Passwort. Keine anderen Social/OAuth-Anbieter (GitHub, Apple, Discord, …), keine Magic Links, Passkeys, OTP, Telefon/SMS oder anonyme Anmeldung. Füge keine Einträge zu GROK_PROVIDERS hinzu. Details zu den Methoden und den Schalter für E-Mail/Passwort (bearbeite nur src/lib/auth/email-password.ts): references/sign-in-methods.md. Ausnahme – Gate-Betrachter sind bereits angemeldet; zeige NIEMALS Login-/Reauth-Buttons für sie an. Connector-/App-Data-Apps: NUR Gate „Weiter mit Grok“, keine Google/X-Buttons: references/grok-identity.md.

Die Anmeldung ist STANDARDMÄSSIG AUS – die Vorlage enthält .grok/app-env.json mit {"VITE_AUTH_ENABLED": "false"}, also füge Konten nur hinzu, wenn die Aufgabe es verlangt (AGENTS.md §0.5). Das Einschalten erfolgt unter „Anmeldung einschalten“ weiter unten.

Wenn eingeschaltet, ist die Anmeldung ECHT – auch in der Sandbox-Livevorschau. Erstelle KEINE Demo-/Mock-/hartcodierten Benutzer. Vorschau: Popup + integrierter Vorschau-Client; bereitgestellt: app-eigener Client + DATABASE_URL + Zero-Click-Gate-Anmeldung (references/prewired-and-env.md).

Solange AUS (VITE_AUTH_ENABLED=false) wird ein Entwicklerbenutzer zurückgegeben, damit eine App ohne Auth ohne angemeldeten Besucher rendert – nur für Entwicklung und Vorschau. Bereitgestellt ist das Flag das der Plattform (immer "true"), daher lehnt requireUserId jeden Besucher ab – Auth-aus-Apps verwenden weder dies noch authMiddleware.

Alles ist vorinstalliert und vorkonfiguriert in src/lib/auth/ – führe kein npm install durch; better-auth ist das einzige Auth-Paket (niemals @neondatabase/*, @stackframe/*, oder @clerk/*). Bearbeite oder überschreibe keine Datei unter src/lib/auth/ – am wenigsten server.ts – außer email-password.ts für sein einziges Flag. Dateizuordnung: references/prewired-and-env.md.

/auth/popup wird bereits vom Vorlagen-Vite-Plugin verarbeitet (vite.config.ts → popup.server.ts): es rendert nie die React-App. Erstelle KEIN src/routes/auth/popup.tsx (oder eine beliebige React-Seite / Client-OAuth unter diesem Pfad) – das würde die vollständige App innerhalb des Popups anzeigen, die häufigste Fehlerursache.

Schreibe niemals eine .env / .env.local / .env.example in dieser Sandbox: Die Livevorschau benötigt keine Umgebungskonfiguration und eine bereitgestellte App erhält ihre Variablen von der Plattform. Die vorhandenen Stellschrauben findest du in references/prewired-and-env.md – mache niemals eine Nicht-VITE_-Variable für den Client sichtbar.

migrations/auth/0001_auth.sql ist das Better Auth Schema – bearbeite es nicht. Es liegt außerhalb des glob-gematchten migrations/-Verzeichnisses (kein Anwender durchläuft es), daher wird es nicht auf Apps ohne Anmeldung angewendet; „Anmeldung einschalten“ kopiert es nach oben.

Anmeldung einschalten

Führe alle folgenden Schritte aus – die Routen allein rendern bereits den ausgeschalteten Zweig:

1. Flag: Lösche den VITE_AUTH_ENABLED-Schlüssel aus .grok/app-env.json und starte den Dev-Server neu. Vite liest die Umgebung beim Start, daher würde HMR die Änderung nicht übernehmen. npm run dev, npm run build und npm run preview lesen diese Datei alle über scripts/with-app-env.mjs, sodass Vorschau und das gebaute Ergebnis gemeinsam umschalten – starte Vite niemals direkt.
2. Schema: cp migrations/auth/0001_auth.sql migrations/0001_auth.sql, dann Neustart, damit es angewendet wird. Es wird durch den Basisnamen in _migrations verfolgt, daher wird eine Datenbank, die es bereits hat, es nicht erneut ausführen.
3. Routen: Füge src/routes/api/auth/$.ts + src/routes/login.tsx hinzu – kopiere beide aus references/wiring.md (die Catch-All-API-Route ist das, was /api/auth/* und den Broker-Callback zum Funktionieren bringt).
4. Abmelden: Ein Login ohne Abmeldeoption ist nicht vollständig – rendere <UserButton /> aus @/lib/auth/gates (verdrahtet signOut(); versteckt Abmeldung für Gate-Sitzungen).
5. Vorhandene Daten: Ummantle die Serverfunktionen der App mit authMiddleware (eine Auth-aus-App darf diese nicht verwendet haben – siehe das neon-Skill). Zeilen, die vor der Einführung der Anmeldung existierten, sind Entwicklungsdaten: verwerfe und erstelle sie neu, es sei denn, der Benutzer sagt etwas anderes – gib sie nicht demjenigen, der sich zuerst anmeldet.

Darauf aufbauen, sobald es eingeschaltet ist

• Anmelden / Abmelden: signIn(providerId) und signOut() aus @/lib/auth/client; GROK_PROVIDERS rendert die Buttons. Das Popup, die Bearer-Token-Übergabe und die Anfrageanbindung sind intern – belasse sie so. Bevorzuge <UserButton /> (es behandelt die ausstehenden und fehlgeschlagenen Zustände); signOut() lehnt bei Bereitstellung ab, wenn der Server niemals bestätigt – fange dies ab. Verwende niemals authClient.signOut(): es lässt den Vorschau-Bearer-Token an jeder späteren Anfrage hängen, sodass der Besucher angemeldet bleibt.
• Benutzer auslesen: useCurrentUser() ist nur zur Anzeige gedacht (null bedeutet wird geladen ODER abgemeldet, daher niemals allein darauf umleiten); verwende stattdessen useCurrentUserState()s isPending als Schutz. Gates (SignedIn, SignedOut, SignInGate, RedirectToSignIn, UserButton) befinden sich in @/lib/auth/gates. CTA-Hard-Regeln, Skeleton und Cookie-SSR-Zero-Flash: references/session-ui.md.
• Benutzerbezogene Daten (obligatorisch): Jede Serverfunktion, die benutzerbezogene Daten berührt, MUSS die vorkonfigurierte authMiddleware verwenden und jeden Lese- und Schreibzugriff auf context.userId beschränken – ein Postgres-Treiber hat vollständigen DB-Zugriff, daher schränkt nichts sonst die Abfrage ein. Halte user_id-Spalten als TEXT; vertraue niemals einer client-seitig gelieferten Benutzer-ID; bei Abmeldung wirft die Middleware UnauthorizedError (401). Code und Deaktiviert-Modus-Semantik: references/per-user-data.md.
• Sicherheitsmodell: Headless-Broker, __Host--Cookies + trustedOrigins und Fetch-Metadata-Geschwisterisolierung sind bereits verdrahtet – schwäche sie niemals, um einen Fehler zu beheben (references/sign-in-methods.md behandelt das Modell und die Behebung von „Ungültiger Ursprung“).