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

8 lines
1.3 KiB
Markdown

## 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.