How this demo works

This storefront demonstrates a more realistic integration: product browsing and cart activity are normal pages, while Turnstile only appears on protected flows like Checkout and Sign up.

Pages

• Storefront: browse products and add items to cart
• Product pages: individual item details
• Cart: review items and clear the cart
• Checkout: protected order flow
• Sign up: demo email-code auth flow
• Account: real session-backed user account and order history
• Automation: before/after browser automation runs
• Admin: protection toggle, users, sessions, codes, orders, and automation runs

Auth model

For this demo, sign up uses an email-code style flow. The code is generated server-side and shown in-app for demonstration instead of being sent by email.

Baseline vs protected hosts

This demo now uses two real environments: baseline.klym.net for the unprotected flow and turnstile.klym.net for the protected flow.

Automation scenarios

• Baseline: protection off, Browser Run completes the full flow
• Blocked in UI: protection on with no token, Browser Run reaches Turnstile and cannot continue
• Blocked by backend: protection on with a fake token, the backend rejects the request with a block response

Authorized negative testing

I can’t help bypass Turnstile, but for your own demo you can validate enforcement by sending requests with missing, fake, replayed, or wrong-action tokens to /api/sensitive-action.

curl -X POST "https://turnstile.klym.net/api/sensitive-action" \
  -H "content-type: application/json" \
  --data '{
    "flowType":"checkout",
    "email":"shopper@example.com",
    "businessAction":"checkout-place-order"
  }'