Cloudflare access pages that shouldn't be cached


Unsure if we messed a configuration on our side, however, it is extremely annoying that CF Access pages are cached, this can lead to people believing that they have the right or wrong settings while all they are seeing is cache.

This example shows one of our employees that previously didn’t have access to an access endpoint, however, because they had visited it earlier, they kept seeing that image until the cache was cleared.

I checked our website and couldn’t find any page rule that could lead to them being cached, has anybody experienced similar behavior?

I’ve never even thought to check. What’s the TTL on that? Is it a 200 response? And I bet it’s at .cloudflareaccess.com, so you can’t override this?

1 Like

I guess Cloudflare is sending incorrect cache-control header value. Are you able to verify that?

1 Like

It’s a very odd error.


The left side is chrome and the right side is firefox (first visit), I tried to access the app with no changes in our dashboard.

It’s a 403 response.
Oddly enough the failures seem to occur while navigating the CF panel as well.
image

Another 3 members of our team reported having the same issue with WARP, forbidden while accessing resources to which they have access.

It seems like this issue is only occurring in Chrome, what could be the cause of that?

There have been no significant changes in the last ~72 hours in our teams settings, however, yesterday Access worked when switching to firefox from chrome. Today, all browsers are giving me a forbidden page. I’m the only one that cant access the problematic endpoint at all, I get a forbidden error no matter the browser or cookies used.

Furthermore, access logs supposedly allowed the login requests.
image

Edit:
Firefox is reporting a wrong IP Address ( The Ray ID changes on each refresh ).

Edge and Chrome both report my real IP Address.

Turns out internet explorer is working.

Update 2:
Tried uninstalling the client, both with BETA and release version, the problem still persists on all machines.

Just so you don’t think you’re talking to yourself, I have been reading these.

It’d probably be worth opening a ticket, and then escalating. This thread will make for juicy reading for some poor Support Engineer who’s out looking for trouble. @SamRhea does pop in from time to time, but if he’s not the one to tag, he’ll know who the right person is.

2 Likes

Currently on a break, as soon as I come back I will open the ticket and hopefully provide new information :wink:

1 Like

Came back to check if things had changed, they have but not in a good way.
At the moment, Chrome reports the wrong IP and firefox gets the wrong one (roles have swapped).
The issue persists in incognito mode as well.

Internet explorer seems to be working (edge, chrome, firefox, internet explorer respectively).

I believe that the issue started right after we began adding a new auth provider (auth0 identity provider), however, whether if we log in with the old (1-time pin) or auth0, it throws the forbidden error “randomly”.
It’s not random per se, in my case it stopped working in Chrome (incognito too), and when I switched to Firefox it worked for 1 day.

Edit: @sdayman I made a ticket, 2276584

I can try disabling the auth0 and I’m confident that it would get fixed, however, we were hoping to be able to use our yubikeys to access our protected endpoints.

Ok, I’ve put it in the Escalation queue, but it might not get seen until Monday.

2 Likes

That’s fine, thank you! I will mess a bit with it and see if I can find a solution in the meantime.

1 Like

So far my only conclusion is that the forbidden error comes due to Access reading the wrong IP.
image

Fortunately, firefox seems to work today for me when I’m on incognito. Chrome still doesn’t want to work either on normal nor incognito mode.

1 Like

Not that this is an appropriate solution, but if you use Dev Tools and set “Disable Cache”, would that make it work? I believe that that sends a no-cache request header.

1 Like

I think that the issue isn’t caching as the ray-id changes each time no? Anyways, I will give that a try and get back with the results.

1 Like

Every request for every asset gets a new Ray-ID. (I mean if you request it again, you get a new Ray ID). That shouldn’t affect caching at the edge.

1 Like

Just tried, no changes in the behavior at all. Later I will try to see if there is any difference between cookies on working vs non-working browsers

1 Like

@sdayman I found the root of the issue

As soon as I disabled this feature everything went back to normal, what’s odd is that the issue propagated to firefox and edge at some point as well.

2 Likes

Whaaa? Is that page even in your domain?

1 Like

The record is just a CNAME that is proxied so technically yes (?). I believe that the proxy part is what broke it, however, I think that it was cloudflared that automatically added this record for us. I could be wrong though.


All examples seem to show that it’s ok to proxy those records.

1 Like