Sure - but what benefits accrue besides replacing HTML content? Cause you don't own the full request - response cycle - so you lose the caching benefit of being able to lookup the cache object - you rely on waiting for a normal response to happen before you can modify it?

It's great for sub-requests and replacing content in HTML

Like - example case, taking a login page and adding CSRF tokens to it dynamically as well as a signed CSRF token to validate against but that actually would be done against one URL

Maybe CSP nonces

Anyone know if Workers Routes override Page Rules for a domain? For example, I have this Page Rule that redirects my domain somewhere else:

mydomain.com/* Forwarding URL (Status Code: 301 - Permanent Redirect, Url: https://myotherdomain.com)

However, I also have a Worker Route that I want to use:

mydomain.com/abc123/

. However, every time I go to

mydomain.com/abc123/

, I'm redirected. Any way around this?

Did you enable the worker route - cause it seems odd the worker route is not dispatched before the Page Rule?

It seems it depends on what type of Page Rule it is..

does event.passThroughOnException counts towards the 100k daily limit? eg. using Router() class for static assets if we return event.passThroughOnException, will it count as a request? as per the doc, it says "with Fail open, Incoming requests will behave as if there was no Worker."

i mean

it wouldnt make sense for it to not count

because you are still executing the worker

but if theres an error, it will send the request to the origin

Yeah. thanks.. wish there was a better way to exclude static assets from these limits.

Thanks for this. Unfortunately, it did not help 😢. Fortunately, I did a Hail Mary Pass and purged the cache for the redirected domain and it worked 💥🎉 .

Anybody using Cloudflare Workers as a way to detect non-human API activity and block? We looked at the Bot Management, but it's expensive - it would double our monthly Enterprise bill. I was thinking of hashing Colo, ASN, User Agent, IP Address and then having it check an automatically generated blacklist (which we run in a cronjob every minute using heuristics like how many searches and how related are the search terms) we would keep on an endpoint and cache at the edge for 30 seconds or so and if they match - block the request. Any better ideas? We could also use Cloudflare Firewall - but this kind of feels better for temporary blocks..

Without having to issue a custom token or a Cookie - is there a way other than hashing what CF gives us - to tell separate clients apart? I imagine it's a privacy issue..

Kind of depends on your goals here. Are you trying to stop attackers, or are you trying to simply identify humans?

If you control the client, you could simply inject a header or something. No (unprejudiced) bot will send you that custom header, but an attacker absolutely might.

@Deleted User reCAPTCHA v3 might fit your needs

recaptcha also requires you to pay for usage after a certain amount

it's one of the big reasons why Cloudflare moved away from it

believe it was $1 per 1000

hCaptcha is a great free alternative (https://www.hcaptcha.com/). It's what Cloudflare switched to, and I wrote a little package to integrate with it here: https://www.npmjs.com/package/@glenstack/cf-workers-hcaptcha

Thanks - will have a look

As someone who tried doing this with lambda at edge, I would recommend just moving to their bot management. we spent so much time and effort trying to build out our own custom solution but it didn't work that well and was way too much hassle. think of all of the time of building + maintaining vs the cost now where I barely think about it. with bot management, you benefit from scale, so cloudflare seeing lots more traffic make it easier to determine bots vs just your domains. not trying to shill, just sharing my experience 😂 . since you're on enterprise I'd recommend asking for a demo, its pretty interesting to see how it all works

You see - now you using logic and I agree with you. Convincing my bosses to put it into a budget = never going to happen. I'm thinking of doing a simple approach first to this and just cover our most computationally intensive route. 🙂

yeah unfortunately we had to the same thing initially. just be sure to log all the time you've spent on it and the continual time and incidents. sooner or later the cost of it will come out and hopefully encourage a switch. don't be afraid to be loud about it too "the squeaky wheel gets the grease"