Cache and security rules!

[Carlos]

I would love to see more cache and security rules that can be easily implemented with one click.

 

[digitalpoint]

Not opposed to adding additional ones. Do you have any specific ideas you are wanting to do?

 

[Carlos]

Secure WP admin url for those who dont want to use CF access

Expression

(http.request.uri eq "/wp-admin")

Then take action
Managed Challenge


Don’t cache WordPress login, checkout, cart, cookies, and more

Expression

(http.request.full_uri contains "/wp-admin") or (http.request.full_uri contains "/wp-login.php") or (http.request.full_uri contains "/checkout/") or (http.request.full_uri contains "/cart/") or (http.request.full_uri contains "/my-account/") or (starts_with(http.request.full_uri, "/graphql")) or (starts_with(http.request.full_uri, "/xmlrpc.php")) or (http.request.full_uri contains ".txt") or (http.request.full_uri contains ".xlst") or (http.request.full_uri contains ".xml") or (http.cookie contains "no_cache") or (http.cookie contains "wp-") or (http.cookie contains "wordpress-") or (http.cookie contains "comment_") or (http.cookie contains "woocommerce_") or (http.cookie contains "PHPSESSID") or (http.cookie contains "solid_visit_id") or (http.request.full_uri contains "/affiliates") or (http.request.full_uri contains "/sign-up/") or (http.request.full_uri contains "/sign-in/") or (http.request.full_uri contains "/change-password/") or (http.request.full_uri contains "/my-account/points-and-rewards/") or (http.request.full_uri contains "/my-account/support-tickets/") or (http.request.full_uri contains "/my-account/subscriptions/")

Action

Bypass cache


I dont know if this is the common one I use and works pretty well with your plugin

 

[digitalpoint]

Secure WP admin url for those who dont want to use CF access

Expression

(http.request.uri eq "/wp-admin")

Then take action
Managed Challenge


Don’t cache WordPress login, checkout, cart, cookies, and more

Expression

(http.request.full_uri contains "/wp-admin") or (http.request.full_uri contains "/wp-login.php") or (http.request.full_uri contains "/checkout/") or (http.request.full_uri contains "/cart/") or (http.request.full_uri contains "/my-account/") or (starts_with(http.request.full_uri, "/graphql")) or (starts_with(http.request.full_uri, "/xmlrpc.php")) or (http.request.full_uri contains ".txt") or (http.request.full_uri contains ".xlst") or (http.request.full_uri contains ".xml") or (http.cookie contains "no_cache") or (http.cookie contains "wp-") or (http.cookie contains "wordpress-") or (http.cookie contains "comment_") or (http.cookie contains "woocommerce_") or (http.cookie contains "PHPSESSID") or (http.cookie contains "solid_visit_id") or (http.request.full_uri contains "/affiliates") or (http.request.full_uri contains "/sign-up/") or (http.request.full_uri contains "/sign-in/") or (http.request.full_uri contains "/change-password/") or (http.request.full_uri contains "/my-account/points-and-rewards/") or (http.request.full_uri contains "/my-account/support-tickets/") or (http.request.full_uri contains "/my-account/subscriptions/")

Action

Bypass cache


I dont know if this is the common one I use and works pretty well with your plugin

Doing a manage challenge on the admin area certainly is something you can do, but all that's really doing is presenting a captcha (even if it's hidden). Personally, I think actually authenticating users at the network level (before the HTTP request even gets to the server) is going to be *much* better protection (which is what the Zero Trust Network Access system gives you).

As far as not caching login, checkout, cart, etc. The plugin is already doing that under the hood when you use the guest page caching option, so adding a cache rule isn't really necessary. That particular expression looks like something that someone might try using if they are using the old school "Cache Everything" mechanism without a plugin (the plugin is internally making decisions on what can/can't be cached on a per request basis already without needing to add a special cache rule to override anything). It certainly wouldn't *break* anything, but using it in combination with the guest page caching option really is just telling it to not cache those things that aren't being cached to begin with.

The guest page caching rule only makes requests *eligible for cache*, it's not a cache everything setup like you had to do in the old days. Whether or not they are *actually* cached is determined by some internal code the plugin.

 

[Carlos]

Thank you for the amazing answer, so in case it will be fine to remove them? and leave the plugin do its job?

 

[digitalpoint]

Thank you for the amazing answer, so in case it will be fine to remove them? and leave the plugin do its job?

I would, ya... But look through your Cache Rules and Page Rules for something that is doing a "Cache Everything". That override rule is probably being used in conjunction with a Cache Everything rule somewhere (this plugin does not add any sort of Cache Everything rule, so if you have one, you'll probably want to figure out why it's there and where it came from). Leaving an old Cache Everything rule, but deleting just its paired rule to bypass that could be problematic if you leave the part that tells it to cache everything.

TL;DR: This plugin doesn't add anything related to a Cache Everything rule (it does it a smarter way).

 

[Carlos]

This is the setup I had before adding your plugin
should I remove them and leave just num#7

it seem your plugin added twice the override cache for R2 bucket

I added it to my end-cache rule

1,2,3

Your plugin added

4,5,6,7

 

[digitalpoint]

Maybe not completely delete until you know things are working as expected, but ya you could disable them as a test before deleting... I don't see a reason that 1-3 would be necessary if you are using the guest page caching option.

As far as the duplicate override for R2 bucket, you might see something like that if you went through the process of setting up an R2 bucket more than once. If they are the same (same hostname and all that), it's fine to delete one. If the hostnames are different, delete the one that isn't relevant to your R2 bucket (like if you did an R2 bucket and then changed the hostname later, delete the one that isn't the public domain for your R2 bucket).

 

[Carlos]

Ok thank you!