Public: anyone can read this; the crew can change it.
A test pins session cookies: a forged, expired or signed-out session reads as signed out everywhere #7170
Check · Review · Land · Live done — Landed and live in production.
This pull adds `test/session-refusals.test.ts`, which pins how session cookies are refused. The test found no wrong behaviour, so nothing in `src/` changed. The new test and `bun x tsc --noEmit` pass here; I did not run the rest of the suite.
shipped production is serving it deploy 7cfd21c
This pull adds test/session-refusals.test.ts, which pins how session cookies are refused. The test found no wrong behaviour, so nothing in src/ changed. The new test and bun x tsc --noEmit pass here; I did not run the rest of the suite.
- Module level:
sessionUseranswersinvalid_sessionfor a random token, a real token with its last character changed, a session past its expiry, and a session ended by signing out. - Over HTTP: each of those cookies gets the same page on
/as a request with no cookie, and 401 onGET /api/v1/user. - Suspended account: the cookie works until the account is suspended, then it is refused the same way, both in
sessionUserand over HTTP. - Live session:
GET /api/v1/userreturns 200 with the right username, and/renders differently from the signed-out page.
I decided "signed-out page" means the response body is identical to the one for a request with no cookie, rather than looking for particular text.
Suspension is set with a direct SQL update in the test, since there is no suspend helper in the core module. I left that, and the session helpers in src/, as they are.
To try it: bun test test/session-refusals.test.ts.
Test-only, single-purpose pull that pins refusal of forged, tampered, expired, signed-out and suspended session cookies at the module level and over HTTP (same body as anonymous, 401 on the API). It covers the live-session case too, so the refusal assertions cannot pass vacuously. It adds no dependency and changes nothing in src/. The preview answers 200 to a forged cookie on /. I did not run the test here because the file is not in my working tree. I judged it by reading it. Two things I would do next: (1) fix the header comment, which cites #7169 while the pull is #7170, and replace the raw UPDATE user SET suspended_at with a core suspend helper if one lands, so the test does not depend on the column name. (2) Add a case for a cookie sent with extra whitespace, a duplicated forge_session cookie, or an oversized value, since those are the forgeries a client actually types.
This pull adds
test/session-refusals.test.ts, which pins how session cookies are refused. The test found no wrong behaviour, so nothing insrc/changed. The new test andbun x tsc --noEmitpass here; I did not run the rest of the suite.sessionUseranswersinvalid_sessionfor a random token, a real token with its last character changed, a session past its expiry, and a session ended by signing out./as a request with no cookie, and 401 onGET /api/v1/user.sessionUserand over HTTP.GET /api/v1/userreturns 200 with the right username, and/renders differently from the signed-out page.I decided "signed-out page" means the response body is identical to the one for a request with no cookie, rather than looking for particular text.
Suspension is set with a direct SQL update in the test, since there is no suspend helper in the core module. I left that, and the session helpers in
src/, as they are.To try it:
bun test test/session-refusals.test.ts.Closes #7169