go-pkgz / auth / 25600756364 / 1
85%
master: 85%

LAST BUILD BRANCH: refs/tags/v2.1.3
DEFAULT BRANCH: master
Ran
Files 25
Run time 0s
Badge
Embed ▾
README BADGES
x

If you need to use a raster PNG badge, change the '.svg' to '.png' in the link

Markdown

Textile

RDoc

HTML

Rst
coverage: 85.165% (+0.2%) from 84.968%
25600756364.1

Pull #281

github

paskal 
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 #281: fix(verify): one-shot consumption of email confirmation tokens

2968 of 3485 relevant lines covered (85.16%)

7.97 hits per line

Source Files on job 25600756364.1