Issue with cached login-redirect

[lenix]

I have a Joomla! 3.6.5 setup running with a custom theme on https://example.com/de/competitons/

In the administrator backend i turned off my caching by setting Global Configuration -> System -> Cache Settings -> Cache to "OFF - Caching Disabled". I also checked the Apache-Configuration like .htaccess and vhost for any settings related to caching, none were present. Also under Global Configuration -> Site -> SEO Settings i activated Search Engine Friendly URLs and Use URL Rewriting, i'm not sure whether this makes any difference though.

Now i have some pages which require the user to log in, so if the user clicks on a link leading to these kind of pages (i.e. https://example.com/de/competitions/aktuelle-begegnungen?task=admin_uebersicht) he gets a HTTP 303 redirect which leads him to a login-page. The URL he is redirected to contains the original URL to go to back to after successful authentication as a base64 encoded part (i.e. https://example.com/de/competitions/component/users/?view=login&return=aHR0cHM6Ly9leGFtcGxlLmNvbS9kZS9jb21wZXRpdGlvbnMvYWt0dWVsbGUtYmVnZWdudW5nZW4/dGFzaz1hZG1pbl91ZWJlcnNpY2h0). I guess something already seems to be fishy over here - as far as i can tell there should be only & instead of & in any URL - i have no idea where this redirect URL is assembled though and didn't investigate any further.

But apart from that, as you can see in the attached screenshot i suddenly also get a "Cache-Control: max-age=2592000" header for that redirect. Apparently sometimes a browser remembered/cached the fact that if it had a request for the original, protected URL it should go to the login-page instead. So after successfully logging in my users didn't end up on the desired protected page, but instead went to the /de/competitions/component/users/?view=login&... URL again, which when already logged in just displays a single logout button - that was quiet confusing to both them and me.

While trying to figure out where this Cache-Control header might have resulted from (since caching seemed to be turned off all over the place) i ended up finding

./libraries/joomla/session/handler/native.php:234:		session_cache_limiter('none');
./libraries/vendor/joomla/session/Joomla/Session/Session.php:618:		session_cache_limiter('none');

After checking http://php.net/session-cache-limiter i realised that 'none' is actually an invalid parameter for this function, so what it apparently did was inserting the Cache-Control with max-age=session.cache_expire into my HTTP headers.

For now i just manually replaced 'none' with 'nocache' in the files mentioned. This resolved my problems just fine, and it sure would be nice to see this change in the official codebase as well - but i still don't really understand what this session_cache_limiter() call is supposed to do in first place?

Some feedback on this would be nice :)

[JVital2013]

I had the same issue and it was fixed by changing 'none' to 'nocache', thanks! I found something interesting though: on a local web server I use for development running Apache 2.4.10, the max-age header does not get sent at all, no matter what session_cache_limiter() is set to. On the other hand, changing session_cache_limiter() to 'nocache' on my main web server sends the no-store, no-cache, must-revalidate, post-check=0, pre-check=0 header. Since I'm using shared web hosting for my main server, the configuration is fairly hidden from me. However, the HTTP headers report the server is nginx, but phpinfo(); reports Apache. Perhaps using Nginx as a reverse proxy compounds the issue?

[lenix]

@JVital2013 is don't think the Nginx is involved since i didn't use any kind reverse proxy in my setup. I really don't get the reason why the developers would use an invalid parameter in first place ^^