Firewall Rule Regex Not Working

Hi,

I’m trying to ascertain how many bots access computationally expensive pages on a web shop. In particular, compound filtered categories.

An unfiltered category URI Path will look like /nl-nl/clothing.html
When they apply one filter for a colour for example, the URI Path becomes /nl-nl/clothing/white.html
When the add a second, the path becomes /nl-nl/clothing/white-blue.html and any further filters applied will get another hypen and the attribute name value at the end eg. /nl-nl/clothing/white-blue-black.html

I now have at the top of my Firewall Rules list this:

(http.request.uri.path matches "^/nl-nl/(jewellery|clothing)/([\\w]+-){2,}[\\w]+\\.html")

I do an Allow (Business account) for brief testing. No errors on saving as there’s no lookbehinds etc.

This works in regex testing tools just fine. But when I then access the site on one of such URLs with said path, Activity Last 24hr remains 0.

Anything with 3 of those filters applied, should get matched. 0, 1 or 2 filters should not. But for the life of me, I can’t get any activity on this firewall rule. It’s at the very top of the list and my IPs (also tried mobile) are not whitelisted. No trailing white spaces etc. What’s wrong with my Regex?

Regular expressions only work on Business plans.

Sorry, my bad, it is a Business plan. Otherwise, the matches option wouldn’t even be there. Other regex rules work just fine.

Shouldnt that work?

^/nl-nl/(?:jewellery|clothing)(?:/.+){3,}\.html$

No, the forward slash shouldn’t repeat. And your version doesn’t take into account the requirement of the hyphen separating the words that needs to be repeated. That’s why I have the last one, where no hyphen exists at the end before .html, as separate.

My version works in https://regex101.com/ but not in CloudFlare. That’s what has me confused. The same rule can be written a thousand other/better ways, but that’s not to say mine shouldn’t work.

You should provide examples of the URL you want to block.

I want to match these as per my original post:

/nl-nl/clothing/white-blue-black.html
/nl-nl/clothing/white-blue-black-brown.html
/nl-nl/clothing/white-blue-black-brown-beige.html
/nl-nl/clothing/white-blue-black-creme.html
/nl-nl/clothing/white-blue-navy-green-black.html
But not with less than 3 filters applied:
/nl-nl/clothing/white-blue.html
/nl-nl/clothing/black.html

If I rewrite your suggestion to this, it works in testing tools, I’ll try that in CF now:
^/nl-nl/(?:jewellery|clothing)/(?:[\w]+-){2,}(?:.+)\.html$

Unfortunately, still no joy. Here’s the current expression preview:

(http.request.uri.path matches "^/nl-nl/(?:jewellery|clothing)/(?:[\\w]+-){2,}(?:.+)\\.html$")

Doesn’t log any activity.

I thought the filters were path based.

I’d try

^/nl-nl/(?:jewellery|clothing)/.+(?:-.*){2,}\.html$

You seem to double escape back-slashes

Or as expression

(http.request.uri.path matches "^/nl-nl/(?:jewellery|clothing)/.+(?:-.*){2,}\.html$")

The double escaping is a known issue, you need to enter it manually.

1 Like

Thanks for your persistence.

I used the expression builder without escaping in there. In the expression view indeed it shows with the extra backslashes. I now put your latest suggestions straight into the expression editor instead of the GUI builder, taking out the extra slashes. That finally makes it work.

I’ll need to tweak it a bit more as it also matches deeper folders, but the most important part is, it finally works. So I suppose the take-away is that you can’t trust the expression builder when it comes to regexes.

(http.request.uri.path matches "^/nl-nl/(?:jewellery|clothing)/\w+(?:-\w*){2,}\.html$")

This is the working one that does NOT also match this extra deeper folder:

/nl-nl/clothing/shirts/goud-paars-wit-geel-bruin-zwart.html

Yes, the double escaping is a known issue.

I read that it was, but thought it’s only a display issue. Not an issue as far as functioning is concerned. Seems it’s indeed a bug that prevents things from working as well as being ugly in displaying the expression. Thanks a lot, got there in the end!

This topic was automatically closed after 30 days. New replies are no longer allowed.