Skip to content
AITroveRead. Build. Understand.
Reading list
Make this comfortable

Project: account access and recovery boundary

Last updated: 5 Oct 20268 min read
project
IntermediateBy AITrove Editorial

Build a small account-access service for a reviewer who needs case 47. The project has four independently testable boundaries: password verification, session issue and revocation, one-use recovery, and case-level permission. A successful password or federated identity check may create a local session, but the case route must still decide whether this reviewer may see that particular record. Keep the public recovery request response neutral for present and absent accounts. The deliverable includes a request/response contract, a storage design for short-lived tokens, and a replay test; a decorative sign-in page does not satisfy it.

Build contract

  • Store a salted slow password verifier through a maintained library, apply a shared attempt budget, and create a fresh session after success.
  • Issue a short-lived one-use recovery token, consume it atomically with the credential change, and apply a documented session revocation rule.
  • Reject an unassigned case on both its direct page route and nested media endpoint, regardless of which sign-in method established identity.

Implementation checkpoint

sql
UPDATE recovery_tokens
SET used_at = CURRENT_TIMESTAMP
WHERE token_digest = :token_digest
  AND used_at IS NULL
  AND expires_at > CURRENT_TIMESTAMP
RETURNING account_id;

Cost and boundaries

Password checks intentionally use CPU and memory, so an unbounded login endpoint can exhaust service capacity. Recovery token and session records add bounded storage with expiry and cleanup work. A case-permission lookup should be indexed, but revocation must reach every worker before a former session can continue to read private data.

Acceptance checks

  • Try a wrong password and an absent account; the public response must not reveal which exists.
  • Race two uses of one recovery link; exactly one may change the credential.
  • After recovery, replay an old session and request an unassigned case and its media URL.

Common Mistakes

  • Treating an account recovery link as a reusable login session.
  • Accepting a case ID because the signed-in UI once displayed its link.
  • Implementing a password hash format in application code instead of using a maintained verifier.

Related lessons

Password Verification and Login Budgets; Account Recovery and Session Revocation; Federated Login Callback Boundary; Sessions and CSRF: keep identity on the server; Authorization: check permission for this record on every request.

web-tech
web-development
Storage details