J3vb/OwnCord
1
0
Fork 0
mirror of https://github.com/J3vb/OwnCord.git synced 2026-09-03 03:50:00 +03:00
Code Issues Packages Projects Releases Wiki Activity

docs(b3-1): Codex round 2 — OC-0378 fix must keep the challenge claim atomic; coverage command syntax

Browse Source 
- OC-0378 suggestedFix: Consume first, restore/re-issue on session failure;
  issuing before Consume lets two concurrent verifies both create sessions
- evidence block: go test -coverprofile=cover.out ./api/ (flag needs a file)

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Rg9QQWVN3E5UUgBD2dydtu
This commit is contained in:
J3vb
2026-08-29 20:55:23 +02:00
co-authored by Claude Fable 5
parent 7c38c2bd1e
commit bf49453cc1
2 changed files with 2 additions and 2 deletions
Download Patch File Download Diff File Expand all files Collapse all files
.superpowers/findings-ledger.json
+1 -1
View File
@@ -8528,7 +8528,7 @@
"why": "handleVerifyTOTP calls partialStore.Consume before issueSession. When CreateSession fails the handler answers 500 \"failed to create session\", but the challenge is already gone (and the code is marked used by VerifyTOTPCodeOnce), so the only way forward is a fresh POST /login with the password. A verified second factor is discarded because of a persistence hiccup that has nothing to do with the credential. Same shape as OC-0376 on the register path.",
"repro": "cd Server && go test -count=1 -run 'TestAuthCharacterization_VerifyTOTPFailurePaths/session_insert_fails' ./api/ — the row installs a BEFORE INSERT ON sessions trigger, verifies a valid code, pins the 500, drops the trigger and pins that the same partial token is now refused with 401.",
"evidence": "Server/api/totp_handler.go:107 if _, ok := partialStore.Consume(partialToken); !ok { // challenge gone here\nServer/api/totp_handler.go:115 token, err := issueSession(r.Context(), database, user.ID, challenge.Device, challenge.IP) // fails after it",
"suggestedFix": "Issue the session first and Consume only after CreateSession succeeded (Lookup already proved the challenge; a concurrent second verify is bounded by the per-user cap and the used-code store), or re-issue the challenge on session failure. Belongs to the AuthService in B3-2/B3-9.",
"suggestedFix": "Keep the claim atomic and first: Consume the challenge before issuing the session (as today), then on CreateSession failure re-issue or restore the challenge for the same user/device/IP so the verified second factor is not discarded. Do NOT issue the session before Consume: two concurrent requests holding the same partial token can pass Lookup with different valid codes from the +/-1 step window (VerifyTOTPCodeOnce tracks (user, code), not the token), both would create sessions, and the losing Consume would leave an unreturned bearer session in the database. If the order must change, the loser has to revoke the session it created. Belongs to the AuthService in B3-2/B3-9.",
"status": "open",
"found": "2026-08-29",
"hunt": "b3-1-auth-characterization-2026-08-29",
docs/plans/b3-server-architecture-guardrails-2026-08-29.md
+1 -1
View File
@@ -299,7 +299,7 @@ TO x_gone` for read faults, `RAISE(FAIL)` triggers for write faults), so no
construction, three mutations stood in for RED: `401→500` in
`totpChallengeSecret` (2 rows RED), `500→401` in `loginAuthenticate` (1 row
RED), `503→401` in `AuthMiddleware` (1 test RED); tree restored.
- **Coverage** (`go test -coverprofile ./api/`, statements, filtered to the two
- **Coverage** (`go test -coverprofile=cover.out ./api/` from `Server/`, statements, filtered to the two
files — B3-2 must not drop it):
| File | Before (`d383d8c7`) | After B3-1 |