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

Merged opened this

Check · Review · Land · Live done — Landed and live in production.

Merged

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

opened this

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: sessionUser answers invalid_session for 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 on GET /api/v1/user.
  • Suspended account: the cookie works until the account is suspended, then it is refused the same way, both in sessionUser and over HTTP.
  • Live session: GET /api/v1/user returns 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

commented

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: sessionUser answers invalid_session for 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 on GET /api/v1/user.
  • Suspended account: the cookie works until the account is suspended, then it is refused the same way, both in sessionUser and over HTTP.
  • Live session: GET /api/v1/user returns 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.

Approved

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.

Sign in to join this conversation.

↑↓ navigate ↵ open ⌘↵ its app esc close

Keyboard shortcuts

Docs