fix(auth): restore canonical Supabase SSR pattern with x-forwarded-host - #835
Merged
Merged
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
tran-christian
force-pushed
the
fix/auth-callback-x-forwarded-host
branch
from
April 19, 2026 16:25
2d8c6e0 to
d575391
Compare
8 tasks
tran-christian
added a commit
that referenced
this pull request
Apr 22, 2026
…easons Session cookies stamped after exchangeCodeForSession are Host-only by default in @supabase/ssr 0.8. On Vercel the response host can be an internal LB, so Set-Cookie attaches to that host even though Location points at www.omshub.org — and the browser never sends the session back. #835 fixed the redirect target via x-forwarded-host but did not touch the cookie scope; the reporter confirmed in DevTools that the PKCE code_verifier lands while sb-<ref>-auth-token[.0/.1] does not. Explicitly set Domain to the registrable domain (omshub.org, derived from the public host with www. stripped) so the session is valid on both www and apex regardless of which host answered the request. Skipped for localhost / IP literals — Host-only is correct there and some browsers reject Domain=localhost. Also split the error redirect into four distinguishable ?reason= values (no_code, exchange_failed, no_session, no_pending_cookies) and add a 60-second non-HttpOnly auth_debug cookie on success so the next sign-in attempt is conclusive from DevTools alone — removeConsole: true strips server logs in prod.
tran-christian
added a commit
that referenced
this pull request
Apr 22, 2026
…easons (#840) Session cookies stamped after exchangeCodeForSession are Host-only by default in @supabase/ssr 0.8. On Vercel the response host can be an internal LB, so Set-Cookie attaches to that host even though Location points at www.omshub.org — and the browser never sends the session back. #835 fixed the redirect target via x-forwarded-host but did not touch the cookie scope; the reporter confirmed in DevTools that the PKCE code_verifier lands while sb-<ref>-auth-token[.0/.1] does not. Explicitly set Domain to the registrable domain (omshub.org, derived from the public host with www. stripped) so the session is valid on both www and apex regardless of which host answered the request. Skipped for localhost / IP literals — Host-only is correct there and some browsers reject Domain=localhost. Also split the error redirect into four distinguishable ?reason= values (no_code, exchange_failed, no_session, no_pending_cookies) and add a 60-second non-HttpOnly auth_debug cookie on success so the next sign-in attempt is conclusive from DevTools alone — removeConsole: true strips server logs in prod.
This was referenced Apr 22, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Fourth attempt at the OAuth session-cookie bug. Reverts the non-canonical
Set-Cookiestamping from #832 and the earlier stagedheaders.appendvariant, returns to the canonical@supabase/ssrNext.js App Router pattern, and adds the one constraint never applied in prior attempts:x-forwarded-hosthandling.Confirmed via DevTools → Application → Cookies on production
www.omshub.orgthat the PKCE-code-verifiercookie lands but the sessionsb-<project>-auth-token[.0/.1]cookies do not — so the redirect response is genuinely failing to stamp session cookies on the user's domain (ruling out the HttpOnly-visibility false alarm).Most likely root cause: on Vercel,
new URL(request.url).originresolves to an internal load-balancer host. The redirect then sends the browser to a different origin than the one@supabase/ssrstampedSet-Cookieon, so the session cookies never end up associated withwww.omshub.org.What changed
app/auth/callback/route.ts:createClientfrom@/lib/supabase/server(already canonical) instead of an inlinecreateServerClientpendingCookies[]buffer,toSetCookieHeader()helper, andresponse.headers.append('Set-Cookie', …)stampingx-forwarded-hostredirect branch (canonical Supabase Next.js App Router example)/auth/callbackproxy exclusion from fix(auth): resolve PKCE code_verifier loss during Google OAuth flow #830 (already inproxy.ts)_fhdiagnostic query param on successful redirect so we can confirm which branch ran in productionWhy the prior attempts didn't land the fix
/auth/callbackproxy exclusion. Correct, kept.response.cookies.set()— merged 51 min after fix(auth): resolve PKCE code_verifier loss during Google OAuth flow #830, before the proxy fix had a chance to be validated.headers.append('Set-Cookie', …). Also non-canonical.Neither stamping variant addressed
x-forwarded-host, which is the one thing Supabase's official example has that ours did not.