Repository navigation
Correct the docs that said beta has no captcha - #249
Merged
Merged
Conversation
Beta now enforces Turnstile on /chat/guest/, using production's keys, so two places that said otherwise were wrong: the beta README's "leaving the secret unset makes the middleware bypass itself, which is what we want", and the deploy script's closing line telling an operator the captcha is absent by design. The README line was doubly wrong after this branch: unset no longer bypasses, it refuses to start. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Follow-on from #248, which merged before this landed. Documentation only.
Beta now enforces Turnstile on
/chat/guest/using production's keys, so two places that said otherwise were wrong:deploy/beta/README.md: "LeavingCLOUDFLARE_SECRET_KEYunset makes the captcha middleware bypass itself, which is what we want." Wrong twice over — beta now has the keys, and after Require a human check on the chat, and stop absence meaning "off" #248 an unset key refuses to start rather than bypassing.~/update-beta-chat.sh(not in the repo): its closing line told the operator "captcha are absent on beta by design" after every deploy.From the adversarial review of the deploy
Three things it turned up, all now handled:
The script could not apply an environment-only change. It short-circuits when the running tag matches, so editing
.env.betaand redeploying did nothing — anddocker restartdoesn't help, because a container keeps the environment it was created with. Added--force, which is what actually turned the captcha on.Rolling back would silently un-gate the chat. A restored container carries its original environment, and the rollback target predates the keys — so
--rollbackwould serve an ungated chat with nothing in the output saying so. It now warns and names the fix. Verified the warning fires against the real saved container.I tested the wrong URL first.
/chat/is a landing page with links, not a gated path; the app is/chat/guest/. My first check found no Turnstile on/chat/and looked like a failure. The real path redirects toverify_captcha_pageand serves the widget, withdata-sitekeymatching the configured key.Verified live on beta
/chat/guest/verify_captcha_page, real Turnstile widgetcaptcha_configuredin containerTruerefusedin 0.0s — not captcha-redirectedThat last row matters most: the endpoint's captcha exemption is a deliberate hole in an authentication boundary, and it still behaves.
🤖 Generated with Claude Code