A Cloudflare Turnstile humanity check for Pithy. One piece of stackable middleware. No tables of its own. It answers one question — is this a human? — and stacks on top of any route's real verification strategy.
@pithy-sh/turnstile
pithy add turnstileA humanity check for the routes that need one: a public signup, the screen where a magic link is requested, a lead form that should be checked quietly.
What it sits on
No tables of its own. It stacks on top of whatever a route already does to establish identity.
The honest bit
A route's strategy answers who is this? — bearer, session, signed-webhook, control-plane, public. A humanity check answers is this a human? They are different questions, so this can never be a route's identity gate. It composes on top of one.
If you build it yourself
The integration is trivial. Knowing what it does not prove is what matters.
It answers whether a caller is human, never who they are. Treating a passed check as identity is the bug it invites.
A token validated in the browser proves nothing at all.
A token replayed is a token wasted; the check has to be consumed once.
It has to stack on a public route, a session route and a signed webhook alike, without becoming the gate itself.
A human who fails the check needs a way forward that is not a dead end.
pithy add turnstileComposes with
In the dashboard
Challenge outcomes per route, so you can see what a bot wave actually hit.
The dashboard is the admin interface for your own application: whatever this capability writes, your team can look up, check and act on from a browser. Reading is free, forever, with no time limit. Connect the project when you deploy.
Everything else
Each one composes the same way. Nothing you skip costs you anything.
One command installs the package, wires its bindings into every environment your project declares, and runs its migrations.