Stop setting the redundant TabAuthToken cookie

[spicermatthews]

Summary

Stops setting TabAuthToken in tokenChangedHandler and explicitly deletes any pre-existing TabAuthToken cookie. This is part 2 of the migration to retire the duplicate Firebase auth cookie that v5 used to read.

Why

v5 used to read TabAuthToken — a 1-2 KB duplicate of the Firebase ID token that we wrote client-side via document.cookie for v5's benefit. As of tab-v5#150, v5 reads the same idToken directly from the dotted TabAuth.AuthUserTokens cookie that next-firebase-auth already manages server-side via apiLogin. With both reads done from the same source, the client-side duplicate is dead weight.

Why this matters

CloudFront access logs show ~3.7% of users are within 3 KB of CloudFront's 32 KB request-size limit and ~8% are over it (most CloudFront edges seem lenient, but the strict ones return 494 errors that users have been reporting). Removing this 1-2 KB cookie pulls borderline users out of 494 territory.

Changes

• Replaced setCookie('TabAuthToken', ...) call with deleteCookie('TabAuthToken', { path: '/' }) so existing browsers actively clear the cookie on the next tokenChangedHandler invocation (rather than leaving it to expire over up to 1 year).
• Removed the now-unused nextYearDate calculation.
• Removed the misleading comment about CloudFront not supporting dotted cookies — verified empirically that CloudFront forwards dotted cookies fine when whitelisted in the origin request policy. The original obstacle was actually PHP's \$_COOKIE rewriting dots to underscores, which v5 now bypasses by reading \$_SERVER['HTTP_COOKIE'] directly.
• Added test asserting deleteCookie is called in both authed and unauthed branches.

v5 fallback safety

tab-v5#150 deployed with a fallback: if TabAuth.AuthUserTokens isn't readable for any reason, v5 falls back to TabAuthToken. Production logs show the new cookie is being read successfully for active v4 users (the population that actually loads tab-web). For users who don't load tab-web (Chrome extension API calls, v1 users) the fallback continues to apply — they still have whatever stale TabAuthToken they had previously, and this PR's deletion only fires when a user does load tab-web.

Test plan

• Deploy
• Hard-refresh tab.gladly.io in a logged-in browser, verify in DevTools that TabAuthToken is gone from the cookie list while TabAuth.AuthUserTokens remains
• Verify v5 routes still work (open new tab → notifications iframe loads, search redirects work, /v5/* pages render)
• In Better Stack, watch for any spike in Auth: fell back to TabAuthToken from /v5/* paths (most fallback should remain on /api/v1/tab/log from extension calls — that's expected and fine)

Follow-up (not in this PR)

• Small cleanup PR in tab-v5 to drop the 5 Blade templates that also set/clear TabAuthToken via document.cookie — those are legacy and now duplicative.
• Eventually: remove the TabAuthToken fallback path in v5 and drop the cookie from CloudFront's v5-request-policy whitelist after confirming the fallback rate is at zero or near-zero.

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
tab-web	Building	Preview, Comment	Apr 23, 2026 4:23am