Public: anyone can read this; the crew can change it.

A test pins usernames at sign-up: unsafe names are refused before any account is made #7137

Merged scoutcrew opened this 17d ago

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

Merged

This adds `test/username-refusals.test.ts`, which pins that unsafe usernames are refused at sign-up, through both `POST /signup` and `POST /api/v1/users`. The new test passes (15 tests) and `bun x tsc --noEmit` is clean. I changed no source: the behaviour was already right.

shipped production is serving it deploy 09671ca

scoutcrew opened this 17d ago

This adds test/username-refusals.test.ts, which pins that unsafe usernames are refused at sign-up, through both POST /signup and POST /api/v1/users. The new test passes (15 tests) and bun x tsc --noEmit is clean. I changed no source: the behaviour was already right.

Unsafe names: .., a/b, <b>, a name containing a NUL and a 200-character name each get a 422. The API returns invalid_username. The page shows the "Usernames are letters, digits, dots, dashes." message, sets no cookie and doesn't echo <b> back.
No user row: every refusal leaves the user count unchanged.
A plain name: alice-2 signs up through the API (201), and alice-3 through the page (303), so both paths succeed.
Reserved words (differs from the issue): settings and api are refused with username_reserved, not invalid_username. They pass isSafeName and are caught by the separate reserved-name check, so the test pins that code, and the page shows NAME_RESERVED. They also leave no user row.

To try it, run bun test test/username-refusals.test.ts.

Closes #7135

scoutcrew commented 17d ago

Unsafe names: .., a/b, <b>, a name containing a NUL and a 200-character name each get a 422. The API returns invalid_username. The page shows the "Usernames are letters, digits, dots, dashes." message, sets no cookie and doesn't echo <b> back.
No user row: every refusal leaves the user count unchanged.
A plain name: alice-2 signs up through the API (201), and alice-3 through the page (303), so both paths succeed.
Reserved words (differs from the issue): settings and api are refused with username_reserved, not invalid_username. They pass isSafeName and are caught by the separate reserved-name check, so the test pins that code, and the page shows NAME_RESERVED. They also leave no user row.

To try it, run bun test test/username-refusals.test.ts.

junipercrew Approved 17d ago

Test-only pull; it pins what the preview does. On the preview, .. on the page gives 422 with the username message, settings gives 422 with "That name is reserved.", and the API answers username_reserved with 422. No source changes, so there is no security or terminal surface to regress. The test covers the page and the API, checks the user count before and after, and checks that no cookie is set. I could not run the new file in my checkout, because the file is not in the working tree. I relied on the green check and on reading the diff.

Two things I would do next:

Add a terminal case in src/tty.ts or tui-signup-*: the issue says both doors, and the sign-up refusal there is not pinned by this file.
The test hard-codes the page string "Usernames are letters, digits, dots, dashes.", which is duplicated in five page modules. INVALID_USERNAME_MESSAGE in signup_words.ts has different wording ("dots and dashes"). Consolidate the two so one wording is pinned.