amanandhishoe

I use the plugin on my WooCommerce login/registration page and the Login and Registration buttons are disabled until Turnstile completes. Perhaps some other plugin or setting is enabling those buttons earlier.

One other thing I’ve done to deal with malicious bots is to put my website behind Cloudflare’s DNS proxy. That way all traffic to the site has to go through Cloudflare first and its WAF. And I do protect my WooCommerce login/registration page with Cloudflare’s JS Challenge which adds another layer of protection. Just a suggestion.

This must be something new as when I first started using Turnstile, I was not getting csp errors with it, and I have a strict csp that evaluates all inline javascript before I send out a page and calculates sha256 hashes to those javascript. The result is that my csp contains an extensive list of allowable hashes for inline scripts. Any inline javascript that does not generate one of those hashes won’t run.
However, I don’t see these csp errors as stopping Turnstile from running. There seem to be calls inside Turnstile that are blocked from running.

It might be interesting to see if bots can access your site using your origin server’s ip. In that case they can bypass Cloudflare. Hopefully it is not possible, but it would be worth a check. SSL should fail in that case, but bots running from a command line don’t care about SSL. WHM can be set to block all requests not using your domain name. Though if bots know your origin server ip, they could still send in requests that appear to be requests to your domain name but route them directly to your origin server and bypass Cloudflare. However, to safeguard against that, you could set your WHM to only accept requests to your site that come from Cloudflare ips. Since you’re using Cloudflare proxy dns service, all legitimate requests must come from Cloudflare ips.

Thanks for the offer for the honeypot code, but I have such code already.

I use URL Path equals.
The only input on my registration page is the email address. I don’t have any hidden input fields on the registration page. So the way I’m adding the JS Challenge requirements is using:
URL Path equals /check-out/
URL Path equals /my-account/
URL Path equals /add-to-cart/
URL Path equals /cart/
And a few other things and the action being “JS Challenge”. Plus I also have Turnstile on the login, registration, and check-out forms.

Maybe it works better for me because I am on Cloudflare’s pro plan and have their super bot fight mode on with the setting to block definitely automated bots. I also have their “Optimize for WordPress” setting on in super bot fight mode.

My reason for going with Cloudflare is I had a huge problem with card fishing bots and bots adding things to a cart and creating hundreds of carts. Before going with Cloudflare I added logic to my custom plugin to stop add-to-cart actions when there were too many within a short time. But after putting my site behind Cloudflare’s DNS proxy and setting up all those JS Challenge rules, I no longer have a problem with bots generating numerous carts. I haven’t had a single card fishing attempt.

It used to be a pain because the company running quarterly PCI scans on my site would generate hundreds and hundreds of carts. Now the PCI scans don’t create a single one.

And maybe my hosting company’s WAF helps. And I also run WordFence on my site too. That might help me from having bots registering. WordFence does maintain a live list of nefarious ips and blocks access from any of those ips. It’s gathering information from millions of websites and updating its list of bad ips constantly.

So to get to the registration page, bots need to get through Cloudflare’s super bot mode, my hosting company’s WAF, and WordFence WAF.

Oh, and one other thing, I do have a mu-plugin that blocks any access that isn’t coming through Cloudflare. So if someone figures out what my origin server is and tries to get to my website that way, my mu-plugin rejects those calls. This is what that mu-plugin looks like:

function allow_mysite_hosts_only() {

	// Set the mysite_love cookie. We use this to see if add-to-cart requests are coming
	// from bots or not. Add-to-cart requests where this cookie is absent are blocked
	// by a Cloudflare WAF rule.
	if ( ! isset( $_COOKIE['mysite_love'] ) ) {
		// Set the cookie for 1 day. Adjust the time as needed.
		$expire    = time() + DAY_IN_SECONDS;      // DAY_IN_SECONDS is a WordPress constant for 24 hours.
		$value     = 'spreading_joy_and_happiness'; // The value of your cookie.
		$secure    = is_ssl();                     // If your site is SSL, set the secure flag.
		$http_only = true;                      // Set true if the cookie is to be accessible only through the HTTP protocol.

		// Add 'samesite' => 'None' to set SameSite attribute to None.
		$cookie_params = array(
			'expires'  => $expire,
			'path'     => COOKIEPATH,
			'domain'   => COOKIE_DOMAIN,
			'secure'   => $secure,
			'httponly' => $http_only,
			'samesite' => 'None', // Set SameSite attribute to None.
		);

		setcookie( 'mysite_love', $value, $cookie_params );
	}

	$allowed_hosts = array( 'mysite.com', 'www.mysite.com' );

	// Sanitize HTTP_HOST.
	if ( isset( $_SERVER['HTTP_HOST'] ) ) {

		$sanitized_host = sanitize_text_field( wp_unslash( $_SERVER['HTTP_HOST'] ) );

		if ( ! in_array( $sanitized_host, $allowed_hosts, true ) ) {

			wp_die( 'Access is not allowed from this host.', 'Forbidden', array( 'response' => 403 ) );

		}

		// OK, we haven't died. Now get the URL. See if it starts with ?p=.
		if ( isset( $_SERVER['REQUEST_URI'] ) ) {

			$sanitized_url = sanitize_text_field( wp_unslash( $_SERVER['REQUEST_URI'] ) );

			// Die if the request is looking for a page and the request is not coming from a
			// logged in admin user.
			if ( ! current_user_can( 'manage_options' ) ) {

				if ( 0 === strpos( $sanitized_url, '/?p=' ) ) {

					wp_die( 'Query denied.', 'Forbidden', array( 'response' => 403 ) );

				}
			}

			// OK, we haven't died. Check to see if the URL starts with /?add-to-cart. These we want to deny.
			// All our /?add-to-cart links never start with that.
			// They are /product-category/some-category/?add-to-cart=nnnn, or at least start with
			// /product. Anything calling /?add-to-cart is a misbehaving bot.
			if ( 0 === strpos( $sanitized_url, '/?add-to-cart' ) ) {

				wp_die( 'Query denied.', 'Forbidden', array( 'response' => 403 ) );

			}
		}
	}
}

My user account page is woocommerce too. These is my JS Challenge logic:

(http.request.uri.path eq “/checkout/”) or (http.request.uri.path eq “/my-account/”) or (http.request.uri.query contains “add-to-cart”) or (http.request.uri.path eq “/cart/”) or (http.request.method eq “POST” and http.request.uri.path contains “/product/”)

I have a few other conditions but those are unique to my site and my custom plugin.

And the action I have selected is JS Challenge.

Not sure if any of these suggestions will help, but these are some ideas from ChatGTP:

Cloudflare’s JavaScript Challenge should block most bots because it requires JavaScript execution, which many automated bots cannot handle. However, if bots are still making accounts on your friend’s WordPress site, there are a few possible explanations:1. JS Challenge is Not Applied to All Registration Requests

• If the?JS Challenge is only applied to initial page loads?but not to the?actual form submission request, bots can bypass the challenge by directly sending requests to the registration endpoint (e.g.,?/wp-login.php?action=register?or a custom registration page).
• Solution: Ensure the?JS Challenge is enforced on both the page load and the form submission endpoint.

2. Session Persistence After Solving JS Challenge

• If Cloudflare’s?JS Challenge is solved once per IP, bots may?solve it once and then continue making registrations?without facing the challenge again.
• Solution: Use?Cloudflare Turnstile?(instead of or in addition to the JS Challenge) to enforce bot checks on?every form submission.

3. Bots Are Using Real Browsers or Puppeteer

• Advanced bots can?run JavaScript in a headless browser?(e.g.,?Puppeteer, Selenium, Playwright) to pass the JS Challenge.
• Solution: Use?Cloudflare Managed Challenge?instead, which detects browser automation techniques better than the JS Challenge.

4. Hidden Fields in the Registration Form

• If bots are?filling hidden fields, it suggests they are?not truly interacting with the page as a human would.
• Solution: Add?honeypot fields?that should remain empty and block form submissions if they are filled.

5. Cloudflare Challenge Mode is Too Lenient

• Your friend might have set the?JS Challenge to Low or Essentially Off, meaning only some requests are challenged.
• Solution: Set?Security Level to High?or create a?WAF rule to enforce JS Challenges on all registration requests.

OK. That might explain why I never see bots making accounts. I use the pro plan and have ‘definitely automated bots’ blocked in my Super Bot Fight Mode.

What is your Cloudflare Super Bot Fight Mode configuration?

And you know it’s a bot because?

I left my Turnstile on, but logically, at that point it is redundant. The JS Challenge downloads a 200K+ minified javascript and runs a whole series of complex calculations to determine if the requestor is a human or not.
You might leave the Turnstile for a while. If new bot accounts stop with the JS Challenge, you might try not using Turnstile.
I left my Turnstile on just to give the users another visual clue, but probably the JS Challenge is sufficient. My understanding is that it does a lot more verifying that you are a human than Turnstile. With Turnstile, if it has any doubts, it will have users verify by showing a box to click. JS Challenge doesn’t do that. It either determines you are a human or not.
I do see you have the JS Challenge on the account page.

Since you are using Cloudlfare, you might consider making a Cloudflare custom WAF rule and putting a Cloudflare JS Challenge on your afee.net/account page. What users would see is a “Verifying to see if you are a human” message which takes a second or two before your account page appears. I’ve found that to be very effective at stopping bots from making accounts, adding items to carts, and trying to check out.

I can’t offer any help, but I use Wordfence 2FA for admin logins and I don’t have an issue using it with Simple Cloudflare Turnstile. The way it behaves for me is that after Turnstile shows OK, I login with my username/email and password, the login panel goes away and Wordfence shows a small panel to enter my 2FA. Enter my 2FA and I am logged in.

I’m just letting you know that Wordfence 2FA can work with Simple Cloudflare Turnstile. I’m thinking there is some plugin/theme conflict going on.

On the Cloudflare Turnstile page you can rotate the keys. Can you set up the plugin with a valid Turnstile key for your domain and then go into Cloudflare and rotate the key for that domain? That would invalidate the key you used to set up the plugin.

This is what happens when I do these steps.
I go to the Appearance->Editor and select Styles->Typography. Then if I select one of the typesets, I see the fonts for that typeset below the list of typesets. In the screenshot below, I selected the 1st Typeset and see that it consists of fonts Fira Code and Manrope.

Now I click on the Fira Code font and the Font Library Panel pops up. I deselect Fira Code and select Bevan font in the Font Library and click the Update button in the Font Library.
Now when I exit the Font Library, I see Bevan font in the list of fonts, however the Typeset I had selected is no longer selected as in the screenshot below:

So even though I added the Bevan font, and I see it in the list of fonts, even though I started with the first Typeset selected, it is no longer selected. This is very confusing behavior. I can select a Typeset and see the fonts for that Typeset. I can click on those fonts, so I would think I am able to edit the fonts in the Typeset, but actually I can’t.

I started with a Typeset selected, thought I could edit the fonts in that Typeset, but when I return from the Font Library the Typeset that was selected before I went to the Font Library is no longer selected. So what is the meaning of the fonts in the font list at this point?

It’s not the list of fonts in the WordPress site. It is a mix of the fonts that were in the Typeset I had selected plus any additional fonts I selected while in the Font Library. And what does clicking “Save” in the editor mean at this point?

I think what contributes to my addled brain’s confusion is that when you click on a Typeset it shows the fonts of that Typeset in the Fonts section. So if you click on a font, and select another font or make a different font selection, it looks like you have changed the fonts in that Typeset. But you have done no such thing. Click on the Typeset you thought you changed, and the font changes you made and which show in the Fonts section are gone.
The Fonts section is this hybrid list where sometimes it displays the fonts of a Typeset, and at other times it displays the fonts in your Font Library.
Since you can’t modify a Typeset, it might be better to have a different way of showing the fonts in a Typeset instead of using the Fonts section to do that.
For example, if you edited the Elements so they don’t use any of the fonts of the Typesets, but fonts you installed in the Font Library, when you bring up Typography again, the fonts in the Fonts section will display those fonts and not any of the fonts in any of the Typesets. But click on any Typeset and you are back in Alice in Wonderland and the only way to get back to the fonts for your site is to undo.
Fortunately, fonts are not something I change often, and once I am satisfied I probably will not bother with the Typography settings again.