auth-yes/scratch/chromium_cookie_investigation.md
Tyler Gillispie b9f4ccd71d feat(auth): resolve mobile cookie shadowing and synchronize tasks/path.md
- Implement iterative session cookie candidate resolution in getAuthenticatedUser
- Eliminate Hono first-match limitation causing mobile login redirect loops
- Use absolute UTC ISO strings for PostgreSQL session expiry queries
- Opportunistically clear host-level cookies upon shadow detection
- Ensure exhaustive server-side session revocation across all cookie candidates on logout
- Add automated regression test for cookie shadowing in server/main.test.ts
- Rename and standardize tasks/path.md with 5-template orchestrator standard
2026-08-24 21:48:33 -07:00

1.4 KiB

Upon research into Chromium bugs and specs regarding Domain=.atyg.org:

  • RFC 6265 defines that a cookie with a Domain attribute is a "domain cookie" and is sent to subdomains.
  • On Android Chrome, when fetch() or window.location.replace is executed immediately after the Set-Cookie header is received, there are known race conditions in the cookie jar sync.
  • Further, if a domain has SameSite=Lax (which Hono sets by default unless specified), it is strictly blocked on cross-site requests, but window.location.replace from login.atyg.org to login.atyg.org/dashboard or another subdomain is still same-site.
  • A critical issue on Android is that sometimes Domain=.atyg.org cookies are dropped during immediate redirects if the exact hostname doesn't perfectly align in the OS-level cookie sync, or if there is a conflict with an already existing host-only cookie for auth.atyg.org vs atyg.org.
  • Hono multiple cookie parsing issue: As we saw in test 1, Hono's getCookie parses the FIRST matching cookie. If auth.atyg.org has a stale host-only cookie session_id=old_stale and the response sets Domain=.atyg.org with session_id=new_valid, the browser might send Cookie: session_id=old_stale; session_id=new_valid. Hono will read old_stale, fail DB lookup, and force a re-login.