Gerhard Scheikl
143fec7971
@supabase/ssr derives the auth cookie storage key from the hostname of the URL it is given (sb-<sub>-auth-token). After routing server-side clients at the internal host (kong-prod), the server looked for sb-kong-prod-auth-token while the browser had set sb-api-auth-token, so server-side getUser() never found the just-established session and bounced the user off the MFA challenge back to /login. Pin every client (browser, server, middleware) to the name derived from NEXT_PUBLIC_SUPABASE_URL via a shared helper so the namespace stays consistent regardless of which API endpoint the client talks to.
19 lines
977 B
TypeScript
19 lines
977 B
TypeScript
/**
|
|
* The auth cookie name that @supabase/ssr would derive from the PUBLIC Supabase
|
|
* URL (e.g. `sb-api-auth-token` for `https://api.linumiq.net`).
|
|
*
|
|
* Server-side clients talk to Supabase over the internal Docker URL
|
|
* (SUPABASE_INTERNAL_URL, e.g. `http://kong-prod:8000`) to bypass the edge rate
|
|
* limiter. But @supabase/ssr derives the cookie storage key from whatever URL
|
|
* it is given, so a server client pointed at the internal host would look for
|
|
* `sb-kong-prod-auth-token` while the browser set `sb-api-auth-token` — the
|
|
* session cookie would never be found and getUser() would return null. Pinning
|
|
* every client to this single, public-URL-derived name keeps the browser and
|
|
* server cookie namespaces in sync regardless of the API endpoint used.
|
|
*/
|
|
export function supabaseAuthCookieName(): string {
|
|
const publicUrl = process.env.NEXT_PUBLIC_SUPABASE_URL!;
|
|
const ref = new URL(publicUrl).hostname.split('.')[0];
|
|
return `sb-${ref}-auth-token`;
|
|
}
|