The link in the magic-link email landed users on the JSON API
endpoint /auth/verify, exposing the raw response body in the
browser. The SPA already ships the wrapper page (verify.html +
verify.js) — it reads the token, POSTs to /auth/verify itself,
saves the JWT, and redirects to /app.html.
Pointing the email at /verify.html restores the intended flow:
operator clicks link → verifying… → 'Signed in as <email>' →
'Go to your notes'.
Verified locally: the LogMailer now emits
http://localhost:18080/verify.html?token=…, GET /verify.html
returns the SPA HTML, and POST /auth/verify still returns the
JWT JSON (unchanged).
internal/auth/ provides:
- TokenStore: 32-byte cryptographically random one-time tokens.
Only the SHA-256 hash is persisted (so a DB leak doesn't grant
active sessions). Comparison uses subtle.ConstantTimeCompare.
Single-use is enforced via UPDATE ... WHERE used_at IS NULL.
- Signer: HS256 JWTs with 24h lifetime, jwt.WithValidMethods to
reject alg=none and other downgrade attacks.
- LogMailer (dev) and SMTPMailer (prod via net/smtp) behind a
Mailer interface.
- RateLimiter: DB-backed fixed window per email; default 5 per
15 min for the magic-link flow.
- Service: orchestrates RequestLogin (auto-creates user on first
login, generates token, emails magic link) and Verify (consumes
token, updates last_login, issues JWT).
- Handlers: POST /auth/login and GET/POST /auth/verify.
HandleLogin returns 202 even on validation failure to avoid
account enumeration; rate-limit hits surface as 429.
Schema additions: magic_tokens (with FK + cascade) and
login_attempts. UserStore.SetStoragePath added for completeness.
Tests cover: token issue/consume, single-use, expiry, rate limit,
JWT round-trip, alg=none rejection, signature tampering, purge,
HTTP handlers (login + verify, missing/invalid token paths).
Closes#9.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
libretech
