Cloudflare delivery, Turnstile and abuse-resistant forms
Learning outcome and trust boundary
Deliver a public funnel while keeping bot verification and business writes authoritative on the server. The browser widget is a challenge UI; it is not proof that a submission is authorized, valid or unique.
Versioned Worker implementation
The Worker serves a public reference response with shared-cache headers and a form/receipt path with no-store. It bounds the request body, parses the fields, validates consent, checks same-origin submission, calls Siteverify, binds the operation key to a payload hash, and stores a stable D1 receipt. Database uniqueness arbitrates concurrent retries.
The test keys are deliberately public testing credentials. Configure a local .dev.vars from the example; production secrets belong in Worker secrets, and production hostname/action settings must match the deployed widget. Never deploy the placeholder database identifier or local test keys as a production setup.
Cloudflare requires server-side Siteverify. Tokens expire after 300 seconds and are single-use. Validate success plus expected hostname and action; treat a verification outage separately from a negative result. The verifier injects fetch for deterministic tests and applies a timeout. See the official validation source below.
Recovery is two protocols
A consumed challenge token cannot simply be retried. Obtain a fresh challenge token while retaining the same business operation key and unchanged validated payload. These lifetimes differ: challenge verification prevents token replay; operation idempotency prevents duplicate acceptance after a lost response. Reset the widget on expiry/error and preserve user-entered fields. A payload change requires a new operation identity or an explicit conflict.
Do not expose receipts through guessable keys. The local exercise uses a random operation ID as a bearer recovery capability; an authenticated product should scope its ledger to account and actor, as the workbench does. Add rate limits, retention and abuse monitoring; Turnstile does not replace these controls or authorization.
CDN and edge decisions
Use cached fetch when its CDN integration matches the delivery design. The Workers Cache API is local to the handling data center and does not itself provide tiered caching. Choose data storage by consistency requirements: eventually consistent KV is suitable for some configuration reads, not an authoritative global one-time approval ledger. Validate these choices against the Cache API documentation and KV consistency documentation for the selected deployment mode.
| Failure | Safe behavior | Diagnostic |
|---|---|---|
| Invalid/replayed token | No database write | Verification category, no token logging |
| Siteverify unavailable | Retryable failure; preserve form | Dependency timeout count |
| Lost success response | Fresh token, same operation returns receipt | Unique operation count |
| Changed payload with old key | Conflict | Payload hash mismatch |
| Stale shell after deploy | Retain assets or recover draft before reload | Asset version and failed chunk |
Exercise and release evidence
Run Worker unit tests and Wrangler's dry build. Initialize local D1 before wrangler dev. Then test official failure/spent-token fixtures through the browser. Local mocks prove the boundary logic, not live challenge effectiveness, Cloudflare cache hits or multi-region behavior. In a controlled deployment, inspect cache headers and region IDs and run a purge experiment. Roll back cache rules independently of form persistence, and never delete accepted receipts to repair the UI.
Executable reference and sources
Implementation · Behavioral evidence · Primary source.
Run the projects and assessment. Human review is pending.