Interesting Cloudflare Pro related problem

bikegremlin

As far as I could test, it seems like Cloudflare Pro, among other cool things, prevents editing custom HTML WordPress widgets.

When CF is disabled (grey cloud, working only as a DNS, not proxy) - everything works fine.

Likewise, websites that don't use Cloudflare Pro (only the free plan) are not affected.

A bit more details - will keep it updated:

Cloudflare - WP Widget problem

This could be a rare problem - I suppose not many people use a similar stack, so it may have gone unnoticed.

pikachu

Have you used devtools to look at the save request and dig into what is being sent?
My guess would be Cloudflare's WAF somehow blocking the request.

dahartigan

Cloudflare DNS will be disabled.

bikegremlin

@stevewatson301 said:
Have you used devtools to look at the save request and dig into what is being sent?
My guess would be Cloudflare's WAF somehow blocking the request.

Likewise.

Thid so - and it did show blocked AdSense scripts.
However, removing AdSense doesn't solve the problem.
It does from time to time - for a very short period.

Very strange.

Couldn't find any blocking shown in Cloudflare's console though.

legendary

Turn off cache and rocketloader. Test.

bikegremlin

@legendary said:
Turn off cache and rocketloader. Test.

Rocket loader is disabled.
Cache is one of the main reasons for using the Pro service.
Disabling it beats the point.
I can temporarily disable proxy though, and don't edit widgets on a daily (even monthly) basis, so that's one workaround.

ralf

@bikegremlin said:
I can temporarily disable proxy though, and don't edit widgets on a daily (even monthly) basis, so that's one workaround.

When you're accessing the site you could go directly to the proxied machine though, no real reason that you have to go through CF yourself.

bikegremlin

@ralf said:

@bikegremlin said:
I can temporarily disable proxy though, and don't edit widgets on a daily (even monthly) basis, so that's one workaround.

When you're accessing the site you could go directly to the proxied machine though, no real reason that you have to go through CF yourself.

How do I do that with WordPress - or any site on a shared hosting server for that matter?

pikachu

@bikegremlin said: How do I do that with WordPress - or any site on a shared hosting server for that matter?

Override your hosts file to point to the IP of your shared hosting provider, and then access the website normally. Might require flushing DNS caches though, killall -HUP mDNSResponder on Mac and something with netns on Windows, look it up

bikegremlin

@stevewatson301 said:

@bikegremlin said: How do I do that with WordPress - or any site on a shared hosting server for that matter?

Override your hosts file to point to the IP of your shared hosting provider, and then access the website normally. Might require flushing DNS caches though, killall -HUP mDNSResponder on Mac and something with netns on Windows, look it up

Thanks.

As expected, there's a browser extension for that too.

Doesn't fly - not with WordPress, in a shared hosting environment, with a properly configured (and "enforced") https connection. Worth a shot though - good idea.

bikegremlin

Solved the WordPress widget update problem with Cloudflare Pro firewall!

TL/DR:
In addition to disabling the “Cloudflare Specials” firewall rules, I had to set the OWASP Sensitivity to “Off” – temporarily, in order to update the widgets.

Security -> WAF -> Managed rules -> Package: OWASP ModSecurity Core Rule Set ->
Sensitivity: Off

These changes propagate practically instantly!

legendary

Ou yes, owasp with their ruleset. On dev it should always be off. Owasp gives incredible headache on commerce sites.

bikegremlin

@legendary said:
Ou yes, owasp with their ruleset. On dev it should always be off. Owasp gives incredible headache on commerce sites.

I believe it’s possible that some of those rules get auto-disabled if you install WooCommerce - because my webshop wasn’t affected by the problem.