tylerg/auth-yes
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
auth-yes/scratch/chromium_cookie_investigation.md
google-labs-jules[bot] 947b38d81a Investigate mobile login cookie persistence bug 
- Investigated Chromium Android wildcard domain cookie behavior.
- Researched Hono's `getCookie` first-match parsing behavior.
- Added experimental Deno test scripts in `scratch/` for Hono cookie header parsing and pg timezone concepts.
- Wrote full root-cause analysis and ranked architectural solutions in `scratch/INVESTIGATIVE_REPORT.md`.

Co-authored-by: mrteye <1945243+mrteye@users.noreply.github.com>
2026-08-25 00:31:19 +00:00

1.3 KiB
Raw Blame History

Chromium Android Wildcard Cookie Behavior

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.