Problem
The Supabase identity auto-bridge (startSupabaseIdentityBridge) only reads the session from localStorage (sb-*-auth-token / supabase.auth.token). That covers SPA-style clients (Lovable/Bolt/Vite on the default @supabase/supabase-js storage), but the default Next.js + @supabase/ssr setup keeps the session in a cookie so the server can read it for SSR/middleware. For that whole class of apps the auto-bridge finds nothing and replay stays anonymous, even though the session is sitting in a JS-readable cookie.
Evidence (a default Next.js + @supabase/ssr app)
- cookie:
sb-<ref>-auth-token = "base64-<base64 json>" — readable via document.cookie, not httpOnly
- localStorage: no auth keys
The session is present and readable, just in a place the bridge does not look.
Desired behavior
With no builder code, a Next.js / @supabase/ssr app's signed-in user is picked up by the auto-bridge and attached to replay (source supabase-auto), the same way localStorage apps already work today.
Sketch
Extend the auto reader to also scan document.cookie for sb-*-auth-token (and reassemble chunked .0/.1 cookies in order), URL-decode, strip the base64- prefix, base64-decode, then feed the result through the existing _sessionFromParsedValue / _identityFromSession path. Keep the 2s poll (cookies emit no change event).
Acceptance criteria
Out of scope
- Server-seeded identity for httpOnly-cookie setups (separate: needs an init-time marker the SDK reads)
- The sign-out / clear-identity gap (tracked in vulk-corp/bworlds#918)
Context
Default session storage differs by stack: @supabase/supabase-js -> localStorage; @supabase/ssr (Next.js / SvelteKit / Remix) -> cookies. connectSupabase(client) and identify() already work for cookie apps; this issue is about the zero-config auto path. Relates to vulk-corp/bworlds#918 (sign-out identity) and the BWorlds dogfooding work.
Problem
The Supabase identity auto-bridge (
startSupabaseIdentityBridge) only reads the session fromlocalStorage(sb-*-auth-token/supabase.auth.token). That covers SPA-style clients (Lovable/Bolt/Vite on the default@supabase/supabase-jsstorage), but the default Next.js +@supabase/ssrsetup keeps the session in a cookie so the server can read it for SSR/middleware. For that whole class of apps the auto-bridge finds nothing and replay stays anonymous, even though the session is sitting in a JS-readable cookie.Evidence (a default Next.js + @supabase/ssr app)
sb-<ref>-auth-token = "base64-<base64 json>"— readable viadocument.cookie, not httpOnlyThe session is present and readable, just in a place the bridge does not look.
Desired behavior
With no builder code, a Next.js /
@supabase/ssrapp's signed-in user is picked up by the auto-bridge and attached to replay (sourcesupabase-auto), the same way localStorage apps already work today.Sketch
Extend the auto reader to also scan
document.cookieforsb-*-auth-token(and reassemble chunked.0/.1cookies in order), URL-decode, strip thebase64-prefix, base64-decode, then feed the result through the existing_sessionFromParsedValue/_identityFromSessionpath. Keep the 2s poll (cookies emit no change event).Acceptance criteria
@supabase/ssrapp with the session only in cookies gets identity set automatically, with noidentify()/connectSupabase()callsb-*-auth-token.0/.1) are reassembled correctlyOut of scope
Context
Default session storage differs by stack:
@supabase/supabase-js-> localStorage;@supabase/ssr(Next.js / SvelteKit / Remix) -> cookies.connectSupabase(client)andidentify()already work for cookie apps; this issue is about the zero-config auto path. Relates to vulk-corp/bworlds#918 (sign-out identity) and the BWorlds dogfooding work.