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
Check · Review · Land · Live done — Landed and live in production.
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
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 givesundefined, andpasskeyIdslists 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 saystoo_manyonce an account holdsPASSKEY_MAX(20), andduplicatefor 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.
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.
This adds
test/passkeys-ownership.test.ts, which proves a passkey belongs to its account. It found no bug, so nothing insrc/changed. The new tests pass andtsc --noEmitis 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 givesundefined, andpasskeyIdslists 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 saystoo_manyonce an account holdsPASSKEY_MAX(20), andduplicatefor 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