[WebTigers]

Found by the new UI probe (PR #364), verified in a real browser, fixed here.

The bug

A password-reset link that had expired, been used, or was malformed rendered a perfectly ordinary "Set a new password" screen. You chose a password, typed it twice, submitted — and only then got "This reset link is invalid or has expired."

The refusal was always correct and safe: fails closed, clear message, nothing written. The defect is that it arrived after the work instead of before it. And the people who hit it are the ones whose link already expired — already locked out, already frustrated.

The error also offered no way forward: "Back to sign in", but no way to request a new link.

The fix

The token is checked on GET. A dead one gets a card that says the link expired and offers a one-click Request a new link → /auth/forgot.

Tiger_Service_Authentication::resetTokenIsLive() is a read-only peek:

• It never consumes the challenge and never costs an attempt, so it's safe at render time. There's an integration test asserting exactly that — peek twice, then redeem successfully.
• It checks the challenge only, not the code. A code can't be verified without spending an attempt, and the challenge id is an opaque v4 UUID the link holder already has — so answering leaks nothing the link itself didn't.
• resetPassword() still re-checks everything at submit. A token can expire between render and submit, so the submit-time gate stays as defence in depth.

Verified on tiger-dev, through the browser

Token	Result
bogus / empty	dead-link card
live	form renders, reset succeeds, signs in at ?pwreset=1
consumed	dead-link card

The middle row is the one that matters most — the guard must not break real reset links. The third is the realistic case: an old link still sitting in someone's inbox.

Tests

Two integration tests in AuthenticationTest:

• a peek doesn't burn the token (peek ×2, then redeem succeeds)
• unknown / consumed / expired / wrong-type challenges all read as not-live — a email_login challenge must never open the reset screen

Mutation-checked: stubbing resetTokenIsLive() to always return true fails them. Full unit suite green (1195 tests); the reset integration tests pass alongside the three pre-existing ones.

i18n

Three new keys, added to all six shipped locales (en/es/pt/fr/de/hi). This isn't optional here — Zend_Translate is configured with disableNotices and no fallback locale, so a missing key renders the raw key as page text on a non-English page. tlh is left alone, consistent with its existing tracked gap.

Scope

core/controllers/AuthController.php, core/views/scripts/auth/reset.phtml, one new @api service method, six language files, one test file. No schema change, no migration, no change to the submit path.

🤖 Generated with Claude Code

https://claude.ai/code/session_013vdyTeoDrGE4hKxt53TsE8