CIDRAM behaviour when Cloudflare Cache Everything page rule is enabled

[soumsps]

I have implemented Cloudflare page rules that enable me to cache everything in there 115 Edge Locations.
I did this to reduce the TTFB time and got impressive result also.
* Result:*

• TTFB 400ms (when page rule disabled) (GTmetrix value)
• TTFB 64ms (when page rule enabled) (GTmetrix value)
  

So, this trick reduces the backend time drastically but makes our site static.

I know when we cache HTML also in Cloudflare that means the client request is not reaching to origin server where we have CIDRAM running.
But when I tested the setup with different VPNs then I was getting the accessed denied page and sometimes not. So the question how the whole system is working because Cloudflare is having 115 edge nodes they might be caching different HTML pages (including accessed denied page) that are generated by the origin server.
What happens if an accessed denied page is cached on Singapore edge node. Then all the client requests routed via Singapore node get accessed denied page ??

Steps to replicate scenario:
Setting the page rule in Cloudflare.

now when we check on GTMetrix domain document header we get cf-cache-status : HIT

CIDRAM is installed from Wordpress repo (without frontend and recaptcha is not enabled).

Sorry, I know this is a weird setup I am planning, all I want is behind the scene information.
After all the suggestion I will plan memcache, redis or varnish. (which ever play well with CIDRAM)

[Maikuolan]

(Sorry for the delay. Been caught up with other things the past day or so. I'll try to reply to this properly a little later today).

[Maikuolan]

Not too weird a setup, and no problem at all. :-)

The issue actually poses a very good question regarding the role of CIDRAM on websites that utilise CDNs and reverse-proxies that operate in this manner. I'm replying a bit later than I'd originally anticipated, but I've thought on this question a bit since first reading it, and I'm not so sure that CIDRAM could work effectively or as intended in a scenario where all content is served statically.

I'm assuming that by "everything", we're meaning both GET and POST requests alike (so no exceptions for end-users posting to contact forms, for example)?

Given that CIDRAM determines whether a request should be blocked on the basis of the information accessible to it regarding inbound requests, and given that in scenarios such as those described above (whereby the end-user never sends any requests to the original server where CIDRAM is installed, and all such requests result in responses serving data statically, via caches generated by the CDN or reverse-proxy, rather than dynamically, via direct or forwarded requests that would still see some response from the original server when necessary), CIDRAM would likely play no role at all in the responses being served to the end-user, its role as a WAF or CIDR/IP blocker becomes moot and redundant, I think.

The only requests that it would have an opportunity to make any determination about, would be those from the CDN or reverse-proxy, when they first send requests to generate their cache, and I doubt they'd be making any distinction between whether they're seeing an "Access Denied" message or the actual website itself; In either case, the cache is generated, and then served off to end-users. At that point, if the cache is generated from the actual website, any "unwanted requests" to that cache would effectively be "missed detections", and if the cache is generated from the "Access Denied" message, any otherwise normal requests to that cache would effectively be "false positives".

I'd be inclined to suggest that perhaps the intended role of CIDRAM, at least in its current form and implementation, is not compatible with an obligatorily static environment.

It may, however, remain compatible in a static environment which is not obligatory (e.g., cache is served to end-users for specific types of requests, such as to static content like images and HTML files, but not with things like POST requests, where responses, whether direct or proxied, instead serve data dynamically from the original server).

Conversely though, as all traffic would be being handled by the the CDN or reverse-proxy in an obligatorily static environment, it becomes the responsibility of the CDN or reverse-proxy to mitigate any potential negative consequences of that traffic, so at least, in terms of hackers, spammers, bandwidth wasters and so on, I don't think CIDRAM would be required so much, in the sense that it would (in theory) all be absorbed by the CDN or reverse-proxy, and never touch the original server anyhow (of course, in an obligatorily static environment, no legitimate users would be capable of sending messages, interacting with contact forms, forums, blogs, etc, either; assuming that the CDN or reverse-proxy is literally handling all traffic without exception, that would include both GET and POST requests alike, meaning users wouldn't be able to interact with forms on websites).

In terms of preventing false positives (whether obligatory or not, regardless), a setup such as that suggested above shouldn't be a problem, as long as it's set up correctly, and as long as CIDRAM is configured correctly (i.e., correct ipaddr value in the case of changed headers, and/or whitelisting any relevant IPs in the case of direct requests to the original server from the CDN or reverse-proxy, so that they don't get blocked when they send their requests).

In terms of missed detections: CIDRAM may be less effective against things like scraping, due to that a scraper could, in theory, just scrape directly from one of the caches, and avoid the original server entirely as a means of avoiding being blocked (I don't think there's really anything we could do about that there, unless the CDN or reverse-proxy provides some way of integrating IP/CIDR blocks directly from their end). It should remain effective against spammers and hackers though, in a non-obligatory environment (i.e., where it still has access to POST requests).

This is probably all something worth adding to the documentation at some point, I think.

[soumsps]

Thank you, for that detailed reply it cleared my doubts. Yes, I have read all the documentation 2-3 times but didn't found much on CDN/ Caching.
I am dropping the idea of caching everything on Cloudflare, as it will defeat the idea of using Wordpress and CIDRAM.

[Maikuolan]

Marking as resolved. Keeping the issue open for now, until I can update the documentation to include the new information. I'll close the issue after the documentation has been updated.

[Maikuolan]

I've added some information to the documentation now about this issue (basically, a shortened/simplified version of what we've already discussed above):

• Will problems occur if I use CIDRAM at the same time as using CDNs or caching services?

Maybe. This depends on the nature of the service in question, and how you're using it. Generally, if you're only caching static assets (images, CSS, etc; anything that doesn't generally change over time), there shouldn't be any problems. There may be problems though, if you're caching data that would otherwise typically be generated dynamically when requested, or if you're caching the results of POST requests (this would essentially render your website and its environment as obligatorily static, and CIDRAM is unlikely to provide any meaningful benefit in an obligatorily static environment). There may also be specific configuration requirements for CIDRAM, depending on which CDN or caching service you're using (you'll need to ensure that CIDRAM is configured correctly for the specific CDN or caching service that you're using). Failure to configure CIDRAM correctly may lead to significantly problematic false positives and missed detections.

Let me know if you think anything needs to be added, changed, etc. Cheers. :-)