Cloudflare causing logout
Permalink 1 user found helpful
I've checked all the forum posts about Cloudflare and C5, and also read this how-to:
http://www.concrete5.org/documentation/how-tos/developers/using-clo...
And I'm finding when a site using C5.6.3.1 with Cloudflare gets the admin user logged out after just a minute or two. I've tested every possible factor, such as APC enable/disable, various browsers, and the only factor that actually fixes the problem is turning off CloudFlare. I'd prefer to keep it if possible, but the site is edited on a daily basis, so turning it on and off isn't really viable.
Also I'd prefer not to setup a "direct" subdomain as recommended in the "how to" for SEO/duplicate content reasons, plus it does confuse the site editors a little.
Anyone else had the same issue and any suggested workarounds?
http://www.concrete5.org/documentation/how-tos/developers/using-clo...
And I'm finding when a site using C5.6.3.1 with Cloudflare gets the admin user logged out after just a minute or two. I've tested every possible factor, such as APC enable/disable, various browsers, and the only factor that actually fixes the problem is turning off CloudFlare. I'd prefer to keep it if possible, but the site is edited on a daily basis, so turning it on and off isn't really viable.
Also I'd prefer not to setup a "direct" subdomain as recommended in the "how to" for SEO/duplicate content reasons, plus it does confuse the site editors a little.
Anyone else had the same issue and any suggested workarounds?
This is happening to us as well, before it was certain settings like rocket loader that would cause it but recently it seems to happen with cloudflare on at all. I tried disabling the minification of js/css/html and any other aggressive settings but it didn't help. I submitted a support ticket with cloudflare and I'll post back here once we figure it out.
Great, I'd love to know your solution. I still have cloud flare disabled on that site but would really like to activate it.
will do.. for now I went with the management subdomain that goes around CF so I could leave CF on and people can keep working. seems okay so far but like you I agree that I would rather not have the subdomain for a variety of reasons.
I was wrong on this it was the auto-minify js option in CloudFlare. mod_cloudflare is fine. the auto minification of the js option is screwing up the session somehow
Cool, thanks for that feedback. It certainly makes sense. It's been a while now, but I recall having the issue before installing the apache module. But I will give it another go anyway. But I think you're on the ball as far as the IP address in the header causing problems. Sometimes the request must be coming directly from the user and other times from the CloudFlare cache. That makes the most sense. I'll also ask my host if they can configure the module to always pass through the user's IP address, although I get the feeling it may be a structural clash between the way C5 works and Cloudflare.
Hi,
Any updates on how you resolved the issue? We are also experiencing the same problem now.
Thanks,
Any updates on how you resolved the issue? We are also experiencing the same problem now.
Thanks,
It's very frustrating the real issue keeps evolving both on CloudFlare's end and with new versions of C5 5.7+ etc so really all you can do is keep trying to toggle various settings with CloudFlare until you figure out which is causing it.
With 5.7+ I actually never found a good solution for one site but another seems fine, there are so many variables, whether you are using their ssl redirects (page rules), the apache mod, what level of security in cloudflare, what minification you are using and then what level of minification and cacheing in C5 etc. It's a real pain actually I'm considering never using CloudFlare again with C5 for these reasons it's just too much of a headache to have another proxy/cache in the middle of a dynamic CMS.
Definitely don't use the js minification that seems to break the admin also.
One tip that may help it seemed to help with me is to use their rules to ignore all requests to the /concrete directories/paths so it doesn't munge the c5 js libraries and so on.
Good luck wish I had more to add but really it's like shooting ducks in a gallery like they say :)
With 5.7+ I actually never found a good solution for one site but another seems fine, there are so many variables, whether you are using their ssl redirects (page rules), the apache mod, what level of security in cloudflare, what minification you are using and then what level of minification and cacheing in C5 etc. It's a real pain actually I'm considering never using CloudFlare again with C5 for these reasons it's just too much of a headache to have another proxy/cache in the middle of a dynamic CMS.
Definitely don't use the js minification that seems to break the admin also.
One tip that may help it seemed to help with me is to use their rules to ignore all requests to the /concrete directories/paths so it doesn't munge the c5 js libraries and so on.
Good luck wish I had more to add but really it's like shooting ducks in a gallery like they say :)
I've had this issue today, after trawling around a few sites, I've found the issue is related to the C5 PHP Session Fixation check.
When you're on Cloudflare, the $_SERVER['REMOTE_ADDR'] is one of the Cloudflare IP's, and not the IP of the connecting user, so I think the sessions are being constantly overwritten on new connections etc. (not 100% sure how this is happening) But I find I only get kicked out when I start connecting to the server on other devices and or browsers.
The fix I've implemented (and appears to be working at the moment, I'm still running a few tests) is by modifying the /concrete/startup/session.php as much as the REMOTE_ADDR element of the $_SERVER variable is a bit messed up, Cloudflare do send the connecting IP to us in the $_SERVER['HTTP_CF_CONNECTING_IP'] variable.
Please note this fix has been applied to 5.6.3.4
This section of code needs to be changed.
To this:
Hope this is useful for people! - Adz
When you're on Cloudflare, the $_SERVER['REMOTE_ADDR'] is one of the Cloudflare IP's, and not the IP of the connecting user, so I think the sessions are being constantly overwritten on new connections etc. (not 100% sure how this is happening) But I find I only get kicked out when I start connecting to the server on other devices and or browsers.
The fix I've implemented (and appears to be working at the moment, I'm still running a few tests) is by modifying the /concrete/startup/session.php as much as the REMOTE_ADDR element of the $_SERVER variable is a bit messed up, Cloudflare do send the connecting IP to us in the $_SERVER['HTTP_CF_CONNECTING_IP'] variable.
Please note this fix has been applied to 5.6.3.4
This section of code needs to be changed.
// avoid session fixation; check IP and UA if (!empty($_SESSION['client']['REMOTE_ADDR']) && ($_SESSION['client']['REMOTE_ADDR'] != $_SERVER['REMOTE_ADDR'])) { // provide new session id and leave the old one session_regenerate_id(false); // wipe new session $_SESSION = array(); } // session defaults if (empty($_SESSION['client']['REMOTE_ADDR'])) { $_SESSION['client']['REMOTE_ADDR'] = $_SERVER['REMOTE_ADDR']; } if (empty($_SESSION['client']['HTTP_USER_AGENT'])) { $_SESSION['client']['HTTP_USER_AGENT'] = $_SERVER['HTTP_USER_AGENT']; }
To this:
// avoid session fixation; check IP and UA if (array_key_exists('HTTP_CF_CONNECTING_IP', $_SERVER)) { if (!empty($_SESSION['client']['REMOTE_ADDR']) && ($_SESSION['client']['REMOTE_ADDR'] != $_SERVER['HTTP_CF_CONNECTING_IP'])) { // provide new session id and leave the old one session_regenerate_id(false); // wipe new session $_SESSION = array(); } if (empty($_SESSION['client']['REMOTE_ADDR'])) { $_SESSION['client']['REMOTE_ADDR'] = $_SERVER['HTTP_CF_CONNECTING_IP']; } } else { if (!empty($_SESSION['client']['REMOTE_ADDR']) && ($_SESSION['client']['REMOTE_ADDR'] != $_SERVER['REMOTE_ADDR'])) { // provide new session id and leave the old one session_regenerate_id(false);
Viewing 15 lines of 26 lines. View entire code block.
Hope this is useful for people! - Adz
This worked me! I wanted to personally thank you for this!
It looks like Cloudflare is aware of the problem, and got the solution:https://support.cloudflare.com/hc/en-us/articles/360029696071...
Steps (1) and (2) resolved issue on our side.
Thank you.
Kind regards,
TY
Steps (1) and (2) resolved issue on our side.
Thank you.
Kind regards,
TY
That's good to know.
I forgot to update this thread some years ago. The solution on newer versions of C5 is to update:
/application/config/concrete.php
Add this code at the start:
Then within the array further down the file, add this:
What it does is tell C5 that all those IP addresses are ok, so if Cloudflare passes traffic from any of those IP addresses, Concrete5 won't invalidate the session cookie and log you out.
Hope this helps someone.
JB
I forgot to update this thread some years ago. The solution on newer versions of C5 is to update:
/application/config/concrete.php
Add this code at the start:
// Allow cloudflare's IPs to avoid user logouts // CloudFlare IPs Sample are belowhttps://www.cloudflare.com/ips/... $remoteIp = [ "173.245.48.0/20", "103.21.244.0/22", "103.22.200.0/22", "103.31.4.0/22", "141.101.64.0/18", "108.162.192.0/18", "190.93.240.0/20", "188.114.96.0/20", "197.234.240.0/22", "198.41.128.0/17", "162.158.0.0/15", "104.16.0.0/12",
Viewing 15 lines of 25 lines. View entire code block.
Then within the array further down the file, add this:
'security' => [ 'trusted_proxies' =>[ 'ips' => $remoteIp, ], ],
What it does is tell C5 that all those IP addresses are ok, so if Cloudflare passes traffic from any of those IP addresses, Concrete5 won't invalidate the session cookie and log you out.
Hope this helps someone.
JB
For newer versions of C5 I was able to use this and it worked like a charm -https://github.com/concrete5/cloudflare_proxy... - you might have to update the IP address list..but it worked.
To handle the issue of confusing site editors you can setup a redirect for the login page to take the editors to the direct subdomain.
As for the SEO issues, I've not experienced that. Modify robots to prevent crawling and make sure that editors do not link to the direct subdomain and you should be fine.