Skip to content

Un-gate the captcha-blocked auth checks: reCAPTCHA off on the test install (TIGER-385) - #370

Merged
WebTigers merged 1 commit into
mainfrom
fix/tiger-385-recaptcha-off-ungates-probe
Oct 25, 2026
Merged

WebTigers merged 1 commit into
mainfrom
fix/tiger-385-recaptcha-off-ungates-probe

Conversation

@WebTigers

Copy link
Copy Markdown
Owner

What

tests/ui/bin/auth-probe.php's GATED footer told the operator that no configuration un-gates the captcha-blocked checks, and that they belong to a headless browser run instead. That's wrong, and it sent the next person down the expensive path.

tiger.recaptcha.enabled = 0 is a first-class state in Tiger_Recaptcha — documented in its own class docblock ("OFF = the control renders nothing and the validator passes, so forms work in dev with no keys"). Switch it off on a test install and the probe's assertions run for real, against the same code prod runs. The keys stay in place, so re-enabling is the same single value.

Why it matters — which three checks

The gated ones were not incidental. They are the probe's three blocker-severity checks:

Check Asserts
AUTH-04 a failed login is refused with a JSON envelope (HTTP 401 + {result:0, message})
AUTH-05 login does not enumerate accounts — two unknown identifiers give an identical refusal
AUTH-07 a reset request does not enumerate accounts

Those are the assertions least able to afford being inconclusive, and they had been inconclusive on every run.

Verified both ways on dev, not asserted

Mutation-checked, because a footer that only ever prints one branch proves nothing:

  • reCAPTCHA ON → 13 checks, 0 failed, 3 GATED and the new footer renders with the config line.
  • reCAPTCHA OFF → 13 checks, 0 failed, 0 GATED.
  • A real headless login (identifier + password, no captcha token) returns {"result":1,"redirect":"/account"}, and an authenticated page fetch returns 200.

dev is left with reCAPTCHA off, which is what a test install wants.

Comment-only change to a test tool — no shipped code, no behavior change.

🤖 Generated with Claude Code

https://claude.ai/code/session_013vdyTeoDrGE4hKxt53TsE8

…st install (TIGER-385)

The probe's GATED footer told the operator the three captcha-blocked checks could not be
un-gated by any configuration, and belonged to a headless browser run instead. That was
wrong. `tiger.recaptcha.enabled = 0` is a first-class state in `Tiger_Recaptcha` — the
control renders nothing and the validator passes, by design, so a keyless dev install just
works — and with it off all three run for real against the same code prod runs.

It matters because of WHICH three: AUTH-04 (a failed login is refused with a JSON envelope),
AUTH-05 (login does not enumerate accounts) and AUTH-07 (a reset request does not enumerate
accounts) are the probe's three `blocker`-severity checks. They were the assertions least
able to afford being inconclusive.

Verified both ways on dev rather than asserted: with reCAPTCHA ON the footer renders and
reports 3 GATED; with it OFF the run is 13 checks, 0 failed, 0 GATED, and a real headless
login (`identifier`+`password`, no captcha token) returns `{"result":1,"redirect":"/account"}`
and a 200 on an authenticated page.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_013vdyTeoDrGE4hKxt53TsE8
@WebTigers
WebTigers merged commit e668077 into main Oct 25, 2026
14 checks passed
@WebTigers
WebTigers deleted the fix/tiger-385-recaptcha-off-ungates-probe branch October 25, 2026 12:06
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant