- 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>
8 lines
1.3 KiB
Markdown
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.
|