@finedine/auth

Login, Cross-Subdomain-SSO und Nutzerdaten. Ein Supabase-Client für alle Apps.

Browser

import { FineDineProvider, RequireAuth, useUser, usePermissions } from "@finedine/auth";

<FineDineProvider config={{ appId: "meine_app" }}>
  <RequireAuth requireApp={{ appId: "meine_app" }}>
    <App />
  </RequireAuth>
</FineDineProvider>;

const { user, profile, loading } = useUser();
const { apps } = useMyApps();
const { isStaff, can } = usePermissions();
const supabase = useSupabase(); // für alles Fachliche

Server (Next.js)

import { createFineDineServerClient, getProfile, getMyApps } from "@finedine/auth/server";
import { cookies } from "next/headers";

const store = await cookies();
const supabase = createFineDineServerClient({
  getAll: () => store.getAll(),
  setAll: (list) => list.forEach((c) => store.set(c.name, c.value, c.options)),
});

Derselbe Client, nur mit einem Cookie-Adapter. Er trägt das Token des angemeldeten Nutzers — RLS greift also auch serverseitig. Es gibt bewusst keinen zweiten, privilegierten Weg.

Cross-Subdomain-SSO

Die Session liegt als Cookie auf .app.fine-dine.de, nicht in localStorage (das wäre origin-gebunden, also ein Login pro Subdomain). Das Chunking übernimmt @supabase/ssr — eine Session ist 2–6 KB, das Cookie-Limit liegt bei ~4 KB, und ein zu großes Cookie wird vom Browser stillschweigend verworfen.

cookieDomainForHost() entscheidet pro Host:

| Host | Cookie | | ---------------------------------- | ------------------------------- | | *.app.fine-dine.de | geteilt | | localhost, 127.0.0.1 | host-gebunden | | *.lovable.app | host-gebunden — nie geteilt | | *.up.railway.app, *.vercel.app | host-gebunden | | alles andere | host-gebunden |

Prototyping auf *.lovable.app mit eigenem Dev-Login ist normal. Produktiv läuft jede App unter app.fine-dine.de.

Abmelden

await signOutEverywhere(supabase, { redirectTo: "/login" });

signOut({ scope: 'global' }) plus explizites Cookie-Löschen — sonst hängen andere Tabs im Zombie-Zustand.

supabase-js

Ist peerDependency mit engem Range. Zwei Client-Instanzen im Bundle bedeuten zwei Refresh-Timer auf demselben Refresh-Token und damit scheinbar zufällige Abmeldungen.