Skip to content

Firebase sign-in fails on p-eop — "Unable to save initial state" (sessionStorage)

Symptom

Authorizing (Firebase Auth) on p-eop.theestablishers.com throws "Unable to save initial state. This may happen if browser sessionStorage is inaccessible." Reported by the owner, 2026-06-21. (p-eop is already a Firebase authorized domain — confirmed by the owner.)

Diagnosis — not Cloudflare, not authorized-domains

  • Not Cloudflare: /auth/signin response headers are byte-identical on eop vs p-eop (same cache-control, cf-cache-status: DYNAMIC, server: cloudflare) — Cloudflare isn't treating p-eop differently, and sessionStorage is client-side (a proxy can't make it "inaccessible").
  • Likely cause: Firebase signInWithRedirect with a cross-domain authDomain (aote-pms.firebaseapp.com ≠ the app host) + modern-browser storage partitioning (Safari ITP / Chrome third-party storage) breaks the redirect round-trip's sessionStorage state. The sign-in code (app/auth/signin/client.tsx) tries signInWithPopup first and falls back to signInWithRedirect; when the popup doesn't run, the redirect fallback throws this. The code uses window.location.origin, so the baked NEXT_PUBLIC_APP_URL=eop is not the cause — i.e. the preview/prod split won't fix it.

Escalation — T-083 (the structural fix)

Escalated 2026-06-21 to T-083 (owner: "Please also proceed to work on I-002"). The fix — same-origin authDomain via a Next.js reverse-proxy of /__/auth/* + per-branch authDomain — is specced there, to be rolled out preview-first (p-eop, then promote to eop). Low urgency: prod (eop) is what the directors use; this is preview-facing.

Closed 2026-06-22 — p-eop dropped, symptom can't recur

  • Source: EOP Local Assistance · session 63c32698-0f80-464c-a668-f352be2c148e (local Claude Code)
  • The owner dropped the NAS preview (T-082): p-eop.theestablishers.com no longer exists (container + image + CI auto-build removed, DNS deleted). This symptom was only ever observed on p-eop, so it can't recur — closing the ticket (resolved by removing the domain, not by fixing the auth).
  • The underlying fragility is NOT gone: the cross-domain authDomain + signInWithRedirect fallback could still bite prod (eop) if a director's browser ever blocks the sign-in popup. That's reframed as latent prod-auth hardening under T-083, which stays open at low priority (no active symptom; popup sign-in is the working path for both directors today).