Zero Trust woes
I have 2 applications in Zero trust
server.domain.com (allows only specific email - mine)
server.domain.com/api* (with bypass everyone rule)
I hit https://server.domain.com/api/v1/lala and still get Cloudflare "enter email" screen.
What is wrong and where can I see logs on why this matches the non-bypass? By documentation any Bypass app is processed first
thank you for your assistance!
10 Replies
try an extra /
example: server.domain.com/api/*
@andrew_nyr I have tried that, also /api/v1* and /api/v1/* ... doesn't seem to match somehow... what makes it even stranger is that on same account an n8n.domain.com/webhook* works fine to bypass (with the same bypass rule exactly used)
What if you remove the trailing asterisks from both rules?
I have a new-found respect for claude code btw... I gave it a read-only api key and cloudflare docs and let it test and do it's thing... (because my brain was hurting trying to find the differences) and here is what it reported:
1. Root Cause Identified: Cloudflare Access evaluates applications based on creation order, not path specificity
2. Why It Failed: The Coolify Admin app (protecting root domain) was created before the webhook bypass app
3. Why n8n Works: The webhook bypass app was created before the root domain protection
Key Learnings:
- Application evaluation order is determined by creation time, not pattern specificity
- This undocumented behavior can cause confusion when setting up overlapping domain patterns
- The solution is to create more specific path applications before broader domain applications in the correct order
The webhook should now work correctly for GitHub to send POST requests with proper payloads!
Amazing? If anyone @Laudian ? has team-access so this can be tested (I did but not thoroughly) and then documented.. (or ideally improved with processing order being selectable in the app config somehow)... it would be GREAT!
like every llm, it's just making up stuff when it lacks explaination in its own sources. Nothing cares about creation time. It's documented that the most specific path wins: https://developers.cloudflare.com/cloudflare-one/policies/access/app-paths/
When multiple rules are set for a common root path, the more specific rule takes precedence
I completely understand what you said but my experience yesterday with it was not that… maybe it was an edge case? maybe I did something wrong too but I deleted and recreated the exact same rules and apps in a different order and it worked for me. Maybe it was a bug 🐛 or caching issue resolved by the delete and recreate. Possible. Hence I said not thoroughly tested. I will try again soon as I have another project
Also when did Cloudflare Zero Trust (formerly Access) go Cloudflare One? 🤗 Hard to keep up with CF names these days
yea I've def created less specific ones out of order before without issue, lots of config options to get confused too
very possible … but I even made a dif before and after between the 2 that didn’t work and another that did
anyhow I really don’t want to waste anyone’s time and I will retest of course soon. Probably my mind going bananas is also a possibility 🤣
All those names are still valid. Cloudflare Access is still the name of the product authing users to access your app. Zero Trust is the higher level item/product, and it's all under the umbrella of Cloudflare One
They started talking about Cloudflare One in 2020 or so: https://blog.cloudflare.com/cloudflare-one/, but I think it was a bit more recently, maybe a year or two ago, they started using the name more in docs and such
that explains it. reaaaaaally messes up AI trying to find docs though lol. I did a search too manually and I guess was also blind. In any case I do thank you kindly 🙏 for your help!! Will report if I find any issues
Look, I love everything CF. Usually great docs too btw - super important… especially with all these products overlapping