Thanks for looking into this @cscharff
Apologies for the delay in response, it’s been quite hectic out here.
So, to elaborate on the use case, I’ll take the ‘Relative URL’ criteria as an example here, please share your thoughts and I’ll try to give similar example/use cases for the other requested criteria as well.
Relative URL Criteria
Let’s take your suggestion as an example:
Eg Scenario 1: The whole sub/domain is behind Cloudflare Access, a new application would’ve to be created just to implement a single bypass rule on an image, imagine that for each asset (the wildcards could be made use of in some scenarios).
Eg Scenario 2: Implementing Cloudflare Access to protect and restric access to key areas of WordPress on a public WP Site. An application would’ve to be created for /wp-admin, another one for /wp-login.php and potentially another one for /MySecretAdminAccessURL (as many WP sites have implemented), just for the sake of protecting the login areas.
For the sake of thoroughness (required for security), we would’ve to put wp api endpoints behind Cloudflare Access as well.
From the Admin perspective: So, just for restricting access to key areas of one WP Site/Installation, a minimum of 3 different applications would’ve to be created and configured separately (without the bypass rules for assets). This would end up causing drift in configurations and make it harder to manage.
From the users’ perspective: Users will see all of these ‘applications’ in the https://test.cloudflareaccess.com app launcher, which would be a little messy.
In scenario 2 above, I guess it’s just a matter of deploying the same Cloudflare Worker for multiple routes? (since Cloudflare Access is running as a CF Worker).
Side note: I've actually had to create 6 different applications just to put 5 URL bypasses inplace! And it made the App Launcher look quite untidy, let alone the CF Teams Console.
Rethinking the CFA Architecture (Application level)
On a related note: Whilst thinking about this from an architeture perspective, it might be better to have the rules/rulesets independent of the application, so that a ‘ruleset’ could be deployed across multiple actual applications (not just URLs), and amended centrally without having to go to each application whenever a change has to be made to the rules.
Afterall, I guess, CFA does make use of KVs here. So, it might even help make the KV size smaller overall, when a common ruleset is used across multiple applications.