Cloudflare Access is a great product, however, it does lack some features which, once it’s there, it’ll open up a wider range of possibilities (and unlock some of the hurdles that I’m facing in adopting it).
Based on the knowledge that Cloudflare Access runs on Cloudflare Workers…
Needs additional criteria options
Relative URL (this would avoid the need to create multiple ‘applications’ just to exclude some paths within an app) See: related issue
Form Data (with/out Regex) at the rules level, than having to create multiple ‘Applications’
Option to have JS functions to validate the criteria
If this then that (additional actions)
The rules seem to be essentially a set of ‘if statements’, so, in addition to the Allow/Block/Bypass options, there should be an additional set within the rule that allows for adding/modifying the request, like adding a cookie or header.
Sorry can you provide some specific use cases you’d like to support and an explanation of why you’d prefer Access for those use cases vs a FW rule for example? While I think I could envision a scenario or two I’d hate to presuppose a use case.
As for this… It avoid the “Chicken and egg conundrum”, whereby, the logo file is sometimes located within the domain that Cloudflare Access is authenticating for, so users won’t have access to the logo file until they authenticate (so, they won’t see it in the login page)!
Without understanding your use case I can’t comment. Lots of options today and more we are considering, that is why I’m trying to understand your specific use case to see if it maps to something we have solved or are considering solutions for.
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.