go-pkgz / auth / 25600204661

85%

master: 85%

Build Type

Pull #281

github

Committed by paskal

Commit Message

fix(verify): one-shot consumption of email confirmation tokens

The email confirmation JWT issued by VerifyHandler.sendConfirmation was
only protected by its 30-minute expiry: any party who could read the
confirmation link (forwarded email, mail-gateway logs, mailbox archive)
could redeem it independently within the window, creating a separate
authenticated session for the same address.

Add a VerifConfirmationStore interface (MarkUsed key, ttl -> bool) and a
default in-memory implementation (sync.Mutex-protected map keyed by
SHA-256 of the raw token). When VerifyHandler.ConfirmationStore is
non-nil, LoginHandler records the token as consumed on first redemption
and rejects replays with 403 "confirmation token already consumed".

The store key is the SHA-256 of the raw token rather than a jti claim,
so existing token fixtures (which carry no jti) are still de-dup'd
correctly without changing the wire format.

Wired through Service.AddVerifProvider in both auth.go and v2/auth.go.
The store is selected once via sync.Once, with this precedence:

  1. Opts.VerifConfirmationStore if non-nil (caller-supplied; required
     for multi-instance deployments — Redis or any shared KV).
  2. provider.NewInMemoryVerifStore() default — fine for single
     instance, broken for LB-fronted multi-instance deployments where
     instance A's "used" set is unknown to instance B. Documented in
     README under "Confirmation token replay protection".

Tests:
* TestInMemoryVerifStore — store-level coverage (replay, expiry, key
  independence).
* TestVerifyHandler_LoginAcceptConfirm_RejectsReplay — integration:
  same token redeemed twice -> 200 then 403.
* TestService_AddVerifProvider_UsesCustomConfirmationStore — Opts
  injection works.
* TestService_AddVerifProvider_DefaultsToInMemory — default install
  + sync.Once reuse on subsequent AddVerifProvider calls.

Pull Request Pull Request #281: fix(verify): one-shot consumption of email confirmation tokens

Coverage Stats

36 of 48 new or added lines in 2 files covered. (75.0%)

19 existing lines in 1 file now uncovered.

2913 of 3434 relevant lines covered (84.83%)

7.83 hits per line