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

A test pins that a passkey belongs to its account: `findPasskey`, `removePasskey` and `notePasskeyUsed` never cross accounts #6801

Merged opened this

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

Merged

This adds `test/passkeys-ownership.test.ts`, which proves a passkey belongs to its account. It found no bug, so nothing in `src/` changed. The new tests pass and `tsc --noEmit` is clean. I ran only this file, not the whole suite.

shipped production is serving it deploy 7cfd21c

opened this

This adds test/passkeys-ownership.test.ts, which proves a passkey belongs to its account. It found no bug, so nothing in src/ changed. The new tests pass and tsc --noEmit is clean. I ran only this file, not the whole suite.

With two accounts holding a passkey each, the four tests check:

  • removePasskey: account A passing B's passkey id removes nothing, and B's is still listed. A passing its own id removes it and leaves B's alone.
  • findPasskey: it finds a credential by its id and returns the owner, the row id and the stored credential. An unknown id gives undefined, and passkeyIds lists only that account's credentials.
  • notePasskeyUsed: it changes only that credential's sign count and last-used time. The other account's credential keeps its count and has no last-used time.
  • passkeyRoom: it says too_many once an account holds PASSKEY_MAX (20), and duplicate for a credential id another account already holds. A different account with room still gets a yes.

To try it, run bun test test/passkeys-ownership.test.ts.

Closes #6797

commented

This adds test/passkeys-ownership.test.ts, which proves a passkey belongs to its account. It found no bug, so nothing in src/ changed. The new tests pass and tsc --noEmit is clean. I ran only this file, not the whole suite.

With two accounts holding a passkey each, the four tests check:

  • removePasskey: account A passing B's passkey id removes nothing, and B's is still listed. A passing its own id removes it and leaves B's alone.
  • findPasskey: it finds a credential by its id and returns the owner, the row id and the stored credential. An unknown id gives undefined, and passkeyIds lists only that account's credentials.
  • notePasskeyUsed: it changes only that credential's sign count and last-used time. The other account's credential keeps its count and has no last-used time.
  • passkeyRoom: it says too_many once an account holds PASSKEY_MAX (20), and duplicate for a credential id another account already holds. A different account with room still gets a yes.

To try it, run bun test test/passkeys-ownership.test.ts.

Approved

Test-only, 84 lines, no src change. Nothing else in test/ calls removePasskey, notePasskeyUsed or passkeyRoom, so the ownership guarantees (the user_id = ?2 on delete, the update touching one row, the cross-account duplicate) were unpinned and each assertion would fail if that clause were dropped. Not pipeline work, but small, single-purpose and not flaky (in-memory db). I could not run the file here: the clone I read had no copy of it, so I judged it against src/core/passkeys.ts. Next: (1) drop the filler expect(k.a).toBeTruthy() and the unused k in the last test. (2) Add a case where account A adds a credential id that account B holds and expect duplicate from addPasskey itself, not just passkeyRoom.

Sign in to join this conversation.

↑↓ navigate ↵ open ⌘↵ its app esc close

Keyboard shortcuts

Docs