Blank page after OAuth login on lbc-2026 (and likely all convention sites)

[nbudin]

Summary

A user reports seeing a blank page after completing the OAuth login flow on lbc-2026.interactiveliterature.org. The symptom: clicking "Sign In" redirects to neilhosting.net, which redirects back to /oauth/callback, but the page never shows content — just hangs blank or briefly shows a spinner and then goes blank.

Nat confirmed this could not be reproduced locally (Firefox and Chrome both worked for him), but the user sees it in both Chrome and Edge.

Evidence

HAR file and JS console screenshot were captured during a failing login attempt.

Console errors

1. POST /oauth_session/refresh 401 — twice, from authenticationManager.performRefresh
2. No HydrateFallback element provided to render during initial hydration — React Router warning
3. Cookie-backed refresh failed; clearing in-memory access token Error: /oauth_session/refresh failed: HTTP 401

HAR analysis

• No /oauth_session/exchange call in the captured requests (87 entries total)
• Two 401s from /oauth_session/refresh, both with empty request cookies
• One successful 200 POST /graphql with currentUser: null
• The exchange call would be entry 88+ — it likely happens after the HAR was saved, just before window.location.href navigates away

Root cause: CloudFront stripping the __Host-intercode_refresh cookie

This was diagnosed and fixed in commit 7b56892 (June 2):

The __Host-intercode_refresh HttpOnly cookie set by /oauth_session/exchange was never reaching the Rails server on subsequent /oauth_session/refresh calls because the CloudFront origin request policy for all dynamic routes uses cookie_behavior = "none", which strips every browser cookie before forwarding to the origin.

The fix adds a new forward_host_with_refresh_cookie CloudFront origin request policy and a dedicated ordered_cache_behavior for /oauth_session/* that whitelists the refresh cookie.

Diagnostic logging added in the same commit was removed in f2fc192 after confirming refresh_token_present=true in production — so the server side is generating the cookie correctly. The Terraform infrastructure fix is the only change needed.

What happens to the user

1. Login flow runs, /oauth_session/exchange succeeds, cookie is set in the browser
2. window.location.href navigates to returnPath (usually /)
3. New page load: bootstrapFromCookie() calls POST /oauth_session/refresh
4. CloudFront strips the __Host-intercode_refresh cookie before forwarding to Rails
5. Rails sees no cookie → 401 → user is not authenticated
6. Convention home page renders without authentication (or if there's a redirect loop back to sign-in, the user lands back at /oauth/callback with a new OAuth code)

The blank page

The page going blank is the brief transition between navigating away from /oauth/callback (after exchange) and the new page loading. The inline CSS spinner added in aebc7fa (June 3) is what the user sees "very briefly" before going blank.

The "No HydrateFallback" warning is expected: RouterProvider renders null during initialization and RouterLoadingOverlay (also from aebc7fa) bridges this gap as a sibling component, but doesn't suppress React Router's internal console warning.

Action required

1. Apply the Terraform changes from 7b56892 — run terraform apply for the CloudFront module so the new ordered_cache_behavior for /oauth_session/* with cookie whitelisting goes live
2. Verify the fix by checking that a login flow results in bootstrapFromCookie returning a valid token (no 401 from /oauth_session/refresh after the exchange)

Secondary: OAuthCallback fallback when login flow data is missing

If a user navigates directly to /oauth/callback?code=... (e.g., from a bookmark, or after sessionStorage is cleared), currentLoginFlowData is null and handleOauthCallback throws "No current login flow found". The error UI renders — but if the user clicks Sign In again from that error page and the new OAuth flow completes, they may end up in a slightly confusing state.

Consider: when currentLoginFlowData is null in handleOauthCallback, automatically call initiateAuthentication to restart the flow instead of (or in addition to) showing the error.

Files involved

• terraform/modules/cloudfront_intercode/main.tf — Terraform fix (committed, needs deploy)
• app/javascript/Authentication/authenticationManager.ts — handleOauthCallback, bootstrapFromCookie, performRefresh
• app/javascript/Authentication/OAuthCallback.tsx — renders during callback, calls handleOauthCallback
• app/controllers/oauth_sessions_controller.rb — Rails endpoints for exchange/refresh/sign-out

[nbudin]

Update from second HAR (Preserve Logs + sensitive data)

After reviewing a second HAR with Preserve Logs and cookie data enabled, the original CloudFront diagnosis needs correction.

lbc-2026 is on Fly.io, not CloudFront

The refresh responses contain via: 2 fly.io, 2 fly.io, not any CloudFront header. The Terraform cookie-forwarding fix only applies to the CloudFront-deployed conventions. This user's blank-page issue has a different root cause.

What the new HAR confirms

Entry 0 is GET https://www.neilhosting.net/.well-known/openid-configuration at 6:26:23.993Z — this is getOpenidConfig() being called by initiateAuthentication ~225ms before the callback page loaded. So currentLoginFlowData was written to sessionStorage. The PKCE flow was initiated correctly.

The rest of the flow (OAuth 302 → callback 200 → two 401 refreshes → graphql 200) is identical to the first HAR, ending at 6:26:24.666Z. No /oauth_session/exchange appears — but the HAR cuts off right when the spinner disappears, about 100–200ms before the exchange would fire in the OAuthCallback useEffect. The user likely stopped recording when they saw the blank page, just before the exchange.

What we still don't know

Because the HAR ends before the exchange:

• We can't confirm whether /oauth_session/exchange actually succeeds
• We can't confirm whether Set-Cookie: __Host-intercode_refresh is returned
• We can't see what page the user lands on after window.location.href = returnPath

Suggested next diagnostic step

Ask the user to:

1. Open DevTools → Application tab → Cookies → https://lbc-2026.interactiveliterature.org
2. Click Sign In, go through the OAuth flow, wait for the blank page
3. Check whether a cookie named __Host-intercode_refresh appears

If present: The exchange worked and the problem is on the landing page (home page rendering, redirect, etc.)
If absent: Either the exchange never fires, the server didn't return a refresh token, or the browser is rejecting the __Host- cookie.

Also worth checking: browser extensions or a corporate security tool that might be stripping/blocking cookies in Chrome+Edge (the issue reproduces for this user in both Chromium-based browsers but Nat can't reproduce it).

[nbudin]

Update: No __Host-intercode_refresh cookie after login attempt

The user confirmed they checked DevTools → Application → Cookies after the blank page appeared, and the __Host-intercode_refresh cookie is absent. This rules out the scenario where the exchange succeeds and the problem is on the landing page.

What this tells us

The blank page is happening on /oauth/callback itself, and one of three things is occurring:

1. Exchange never fires — OAuthCallback's useEffect doesn't call handleOauthCallback, so no POST to /oauth_session/exchange
2. Exchange fires but server doesn't set the cookie — server returns 200 but Set-Cookie is missing
3. Exchange fires, cookie is set, but browser rejects the __Host- cookie — possible with unusual browser config

What's ruled out

• CloudFront cookie stripping (this is Fly.io, via headers confirmed)
• SessionStorage wipe (user doesn't see "Authentication Error: No current login flow found", so currentLoginFlowData was present)
• NOT_AUTHENTICATED GraphQL errors triggering a login restart (HAR confirmed no such errors in AppRootQuery or AppRootLayoutQuery responses)
• Redirect from appRootLoader to /clickwrap_agreement or /my_profile/setup (only happens if currentUser is non-null, which it isn't since no session exists)

Critical next diagnostic step

Ask the user to open Network tab in DevTools before clicking Sign In, go through the full flow, and then scroll to the bottom of the Network tab after the blank page appears. Specifically look for:

• Does /oauth_session/exchange appear? (method: POST)
• If yes: what HTTP status code does it return?
• If yes: does the response include a Set-Cookie header?
• What URL does the browser show when the blank page appears? (is it /oauth/callback, /, or something else?)
• Are there any console errors at the moment the blank page appears?

Also worth asking: Does the user have any browser extensions that might block cookies or intercept network requests (e.g., privacy extensions, ad blockers, corporate security tools)?

Possible code-level fix to consider

If the exchange is firing but the browser is rejecting the __Host- cookie due to a SameSite=Strict edge case (e.g., the OAuth redirect chain puts the final request in a cross-site context), one option would be to change same_site: :strict to same_site: :lax on the refresh cookie. However, the security review comment in oauth_sessions_controller.rb explains why SameSite=Strict was chosen — this would need careful evaluation.

If the exchange is NOT firing at all, the cause would be something preventing OAuthCallback from mounting or its useEffect from running, which is harder to diagnose remotely. In that case, we should consider adding temporary client-side console logging to the component.

— Diagnosed by Claude Sonnet 4.6