Maybe by testing it on localhost a few times. However, I doubt it. Though this isn’t that helpful since I cannot see in the log that this was blocked, and able to unblock again from my own site.
Having an aggressiveness-setting would fix it. Since I’d make the setting really mild. To just not have the Russian spammers, and the Viagra-sending idiots.
From reading this forum it seems that it isn’t that uncommon. I’m afraid it’ll block a lot of legitimate users.
Of course I’m not asking for what you are insinuating.
I was asking for a way to make Turnsile less aggressive or have some options to tune it specifically for our site. Like, if the message is written in Norwegian or from a Norwegian IP, that should be a big boost for these particular site (and only these, manually config’d so), English okay, any other language is likely spam.
Turnstile might want to go with a pure no-config approach, which makes sense, if it would work. And maybe it will, but
Well, me sending isn’t really a problem. But it’s a smoke test to see if it works, and that clearly fails.
The russian spam problem has gotten real big. They’re posting 10-50 messages daily, which is nothing for big sites, but a lot when it goes into a small organizations’ mail box. I like Cloudflare’s no-cookie method. It seemed like a really good solution. But it might not be ready for prime time.
It could be due to me using a non-standard browser like Vivaldi. Or running an ad-blocker. Or any other weird signal which shouldn’t mean you’re a spammer. Anything I can think of, except myself testing it on localhost, is something which would block real users.
I figured it out, and it’s quite embarrassing. But first, that is a good suggestion.
I did try them both, only each “extreme” on different sites though. One fully hidden, one with optional interaction.
It was only one site that was always failing me. The other one which I did first and used the hidden option I think only failed once.
So for the second site, I actually managed to use the secret key of the other site. So it was wrong. The logs were unavailable on that site (using fastcgiwrapper, and for some reason → no logs), which is how I’d be able to do such an elementary and absolutely embarrassing mistake.