it's best practice to store a turnstile secret key in the wrangler.toml secrets space right?
it's best practice to store a turnstile secret key in the wrangler.toml secrets space right?
ISecrets are not stored in wrangler.toml (they're manually added via
wrangler secrets put), but yes.IWrangler.toml is plain-text and non-encrypted, so secrets are better for storing keys.
Cahh ok
Cthanks!
Calong those lines, how do I access a secret in a page function? it doesn't seem to be passed in through the env variable through the fetch request
Cat least, when I iterate through the env object, it doesn't seem to have my secret
HHave you tried accessing the secret directly, rather than iterating?
Cyeah I get null when I log it. maybeeee it's because CF obfuscates my secret when put through a console log but my turnstile is failing so I'm trying to debug through that
CI'm accessing it as env.SECRET_KEY (I know the env variable is being assigned correctly because I have a KV binding that works from it)
Chm ok to "confirm" I'm not getting the right secret value, this is the error code from site verify
C"error-codes -> invalid-input-secret"
Cargghhh ok. I think it's because I tried entering the secret through wrangler
Cwent through the CF dashboard and the secret seems to be available. But I had run
wrangler secret put SECRET_KEY and even though it seemed to push the secret, it doesn't seem like it worked
Sit would be really helpful either having a clearance cookie set the js detections field to true or if there was a seperate "is_cleared" bot management field avaiable in workers
Sunfortunatley turning on js detections for the whole zone causes issues in webviews, so we may have to resort to creating custom clearance cookie in rate limiting workers, which is far from ideal
Swe probably will, it will most likely just be less sophisticated than cloudflare's implementation
IIs there a way to make Turnstile work from a desktop app? I tried registering the app's URL schema in the domain settings (say it's
My Supabase Auth requires Turnstile captcha token to be passed in, so can't really skip that in the desktop app login.
app.electron://, so I added app.electron), but still get the Invalid domain error when the app is packaged.My Supabase Auth requires Turnstile captcha token to be passed in, so can't really skip that in the desktop app login.
FI'm not sure but maybe login in a spawned browser window?
JHi everyone ,
I have an issue with turnstile . I have made an issue in the community website : https://community.cloudflare.com/t/cannot-initialize-widget-element-not-found/666742
Is it possible to get more help ?
Thanks in advance
I have an issue with turnstile . I have made an issue in the community website : https://community.cloudflare.com/t/cannot-initialize-widget-element-not-found/666742
Is it possible to get more help ?
Thanks in advance
Jcan I ask why ? :bibicat:
SIs it possible to get a sitekey without having a registered website (in the websites section) on cf?
JThanks @Leo , fixed my issue using
slotsCI built a turnstile in a dev environemnt but I had the key hardcoded in the HTML. is the best practice to define the keys by environment in the wrangler.toml file?
Cbut how would I flip it per environment?
Cyeah but I have a sitekey for dev and a sitekey for prod. Somehow I'd need to identify the environment to populate the turnstile element with the relevant sitekey. Tryign to think of how
Cok I found
NEXT_PUBLIC_ should work but is this a best practice for turnstiles? I can't find any documentation on nitCwell the sitekey needs to align with the domain, no? so if I have a preview and prod environment (prod would be a custom domain in this case) I would need different sitekeys for both
Cif I hardcode my preview sitekey in the turnstile, my prod turnstile won't work (I get this error)
C
EYou can add multiple domains, and if you add a domain then all subdomains are included automatically.
So for a Pages project for example just add
So for a Pages project for example just add
example.comexample.pages.dev and youre good to go with one sitekeyCahhh didn't know that, thank you!
BHello I have a problem with the turnstile. It works like a charm on desktop version of my website but when I change the view to mobile by developer options on the browser, it never completes. What could be the problem. On either version the turnstile script and turnstile div is loaded with same.
L@Burak ER I have a custom mobile view(s) with the right dimensions, but not overriding the User Agent - then Turnstile works in mobile mode in dev tools.
HNo. Basically, it allows you to send the
/siteverify request multiple times, as long as the same idempotency_key is provided. I would probably place it as part of the form the user submits, so every submission includes the generated keyHI would go:
- User requests form
- Form is returned with the
idempotency_keypre-set by the backend - User submits form
- Site Verify with
idempotency_keyfrom form returns sucess
Later... - Site Verify same form with changed data, but same Turnstile token and
idempotency_keyreturns sucess
VContinuing this train of thought, when would it make sense to have a new
idempotency_key? Different form on the same page? Different form on a different page? Or a whole new user session?
HOk so this is how I understand it. I am not on the #
turnstile, so take what I say with a grain of salt.
The
turnstile, so take what I say with a grain of salt.The
idempotency_key is there for when submission of the form/action can fail, even if the Turnstile check succeeds. For example, say you have a form with the following fields:- Name
- Email Address
- Profile Picture
- Turnstile Check
The Name and Email are saved to a database, but the PfP is uploaded to object storage. You experience that the PUT to object storage fails intermittently, so you want to be able to retry the upload by resubmitting the form.
idempotency_key to the form(in a hidden field), that persists on retry, then once the Turnstile Check is completed once, it can be reused(without failing) when a submission is retriedHShould be done now
HYeah, I was just highlighting why you might want to retry a request
