@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.
16 lines
573 B
TypeScript
16 lines
573 B
TypeScript
'use client';
|
|
|
|
import { createBrowserClient } from '@supabase/ssr';
|
|
import { supabaseAuthCookieName } from './cookie-name';
|
|
|
|
export function createSupabaseBrowserClient() {
|
|
return createBrowserClient(
|
|
process.env.NEXT_PUBLIC_SUPABASE_URL!,
|
|
process.env.NEXT_PUBLIC_SUPABASE_ANON_KEY!,
|
|
// Explicit (equals the default it derives from the public URL) so the
|
|
// server clients can pin the identical name while talking to the internal
|
|
// API host. Keeps both sides on the same auth cookie.
|
|
{ cookieOptions: { name: supabaseAuthCookieName() } },
|
|
);
|
|
}
|