@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.
33 lines
1.1 KiB
TypeScript
33 lines
1.1 KiB
TypeScript
import { createServerClient } from '@supabase/ssr';
|
|
import { cookies } from 'next/headers';
|
|
import { supabaseAuthCookieName } from './cookie-name';
|
|
|
|
export function createSupabaseServerClient() {
|
|
const cookieStore = cookies();
|
|
return createServerClient(
|
|
// Prefer the internal Docker URL so server-side calls skip the Caddy edge
|
|
// (and its rate limiter); fall back to the public URL when unset.
|
|
process.env.SUPABASE_INTERNAL_URL ?? process.env.NEXT_PUBLIC_SUPABASE_URL!,
|
|
process.env.NEXT_PUBLIC_SUPABASE_ANON_KEY!,
|
|
{
|
|
// Pin the cookie name to the public-URL-derived value so it matches the
|
|
// browser client even though we point the API at the internal host.
|
|
cookieOptions: { name: supabaseAuthCookieName() },
|
|
cookies: {
|
|
getAll() {
|
|
return cookieStore.getAll();
|
|
},
|
|
setAll(toSet) {
|
|
try {
|
|
toSet.forEach(({ name, value, options }) => {
|
|
cookieStore.set(name, value, options);
|
|
});
|
|
} catch {
|
|
// Called from a Server Component — middleware will refresh.
|
|
}
|
|
},
|
|
},
|
|
},
|
|
);
|
|
}
|