fix: secure cookie handling for multi-level subdomains

[pfergi42]

Problem

Session cookies with Domain=.example.com; Secure flag are not persisting when accessed from multi-level subdomains like dev.app.example.com, despite working correctly on single-level subdomains like app.example.com.

Root Cause

Chrome's third-party storage partitioning features (ThirdPartyStoragePartitioning and PartitionedCookies) interfere with the proper handling of secure domain cookies on multi-level subdomains. This causes Chrome to create non-secure, host-specific cookies instead of respecting the server's secure domain cookies.

Evidence

SQLite cookie database analysis showed:

-- Server sends: Domain=.example.com; Secure
-- Chrome stores:
.example.com | connect.sid | is_secure=1  ✓ (domain cookie)
dev.app.example.com | connect.sid | is_secure=0  ✗ (overrides with non-secure)

The host-specific non-secure cookie overrides the domain-wide secure cookie, preventing cookie transmission on HTTPS requests.

Solution

Disable ThirdPartyStoragePartitioning and PartitionedCookies features via Chrome launch args to restore correct cookie handling behavior.

Testing

Verified that this fix resolves the issue documented in #421 where:

• Before: dev.app.example.com - cookies not sent (401 errors)
• After: dev.app.example.com - cookies sent correctly (200 OK)

Impact

• Fixes session persistence issues for applications using multi-level subdomain environments
• No breaking changes - only adds Chrome feature flags to disable problematic behavior
• Cookie storage and transmission now matches regular Chrome behavior

Fixes #421

[google-cla]

Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

View this failed invocation of the CLA check for more information.

For the most up to date status, view the checks section at the bottom of the pull request.

[pfergi42]

✅ Fix Verified - Test Results

I've tested this fix on dev.app.example.com and can confirm it resolves the cookie persistence issue completely.

Test Environment

• Domain: dev.app.example.com (multi-level subdomain)
• Server: Express.js with express-session, PostgreSQL session store
• Cookie Config: Domain=.example.com; Secure; HttpOnly; SameSite=Lax

Results

Before Fix:

• Login POST: ✅ 200 OK
• /api/user GET: ❌ 401 Unauthorized (cookie not sent)
• Dashboard: ❌ Stuck on auth page

After Fix:

• Login POST: ✅ 200 OK
• /api/user GET: ✅ 200 OK (cookie sent correctly)
• Dashboard: ✅ Loads successfully
• No authentication errors in console

Network Request Timeline

https://dev.app.examle.com/api/user GET [failed - 401]  ← Before login
https://dev.app.example.com/api/login POST [success - 200]  ← Login
https://dev.app.example.com/api/user GET [success - 200]  ← After login ✅

The secure session cookie is now properly stored and sent on all subsequent HTTPS requests to the multi-level subdomain.

Production Comparison

Both environments now work identically:

• app.example.com (single-level) ✅
• dev.app.example.com (multi-level) ✅

This fix enables proper testing of staging/development environments that use multi-level subdomain patterns, which is a common deployment strategy.

Ready for merge! 🚀

[pfergi42]

@googlebot I signed the CLA

[OrKoN]

Closing the PR because the issue was resolved in another way.