[#4960] - Force-SSL causes a session dropping issue
- Closed
- 8 May 2016
- Medium
- Build: master
- # 4960
To reproduce:
0) Ensure your .htaccess/webserver is NOT doing http to https redirection
1) Enable "Force-SSL" (whole site) in your Joomla system configuration (on an HTTPS capable joomla instance of course)
2) Go to your website frontend in HTTPS and log in
3) Open your site in plain http
4) You get back redirected to SSL but.... session is lost you're logged out
This can be a nasty issue, as users may have bookmarked some http links, external links, and also it happens if they open another tab and they rely to the browser address bar suggestion (if it's stored as plain http).
THIS ISSUE IS SOLVED IF YOU LET THE WEBSERVER HANDLE THE HTTP TO HTTPS REDIRECT
So it's 100% a Joomla issue. Maybe the redirect is not called before any session handling code and the session.php as cannot find a session cookie when is hit in https due to the "secure cookie" finds the user as guest and does some JSession initiation (session_destroy?) that destroies any existing https session, then it redirect the user back to https but with session lost
See:
This is good, but it's related to the issue, JSession should be fixed to avioid clearing on session initiation or the ForceSSL should be implemented in a way no other code is called but just the redirect!
Best Regards,
Stefano
jissues-bot
- | Labels |
Added:
?
|
||
vdespa
- | Category | ⇒ | Authentication Libraries |
This has a (closed) duplicate in #7138
Although I would work around this in .htaccess, I still view this as a bug: If we want to maintain the "Force-SSL" option, we should have it work, always.
My guts says that we should enforce that option very early, before storing a session cookie.
I'll look into this, but of course I'm not promising anything! 
What you wrote in #7138 is correct and it is what is now done in JRouterSite::parse() (lines 73-78).
The problem is that at that point the application (CMS) has already been instanced and with it a (new) session has been created.
We should do that before session initialization, but at a point where we can get Joomla! configuration options, and we should also remember that the force_ssl option is available for the backend too...
I'm currently reading the code trying to identify the correct point where to move that check/redirect, but it is not an easy task (not for me, anyway!).
In any case I think that if you want to enforce SSL for both front-end and back-end, the easiest and by far fasted solution is to do that .htaccess (or equivalent) level.
Hi @smz, yes i agree that best way is to do this at server-level (.htaccess) and I do that way (I use HSTS not simple redirects).
But the common Joomla user doesn't do that, if they have the Joomla option to enforce SSL they'll use it as it's easier to enable (I work often with other site managers as a freelancer and I see this situation)
If best pratice should be to do that at server level, please simply remove the option to enforce SSL in the Joomla code (maybe keeping hidden legacy support but not presenting the UI control in system settings) or add simply a notice aside it asking to enable it also at webserver side (like it's done for URL rewriting) , providing a - commented - example in the default .htaccess
Closing as it is the expected behaviour that switching between http and https it is a new session
This comment was created with the J!Tracker Application at issues.joomla.org/joomla-cms/4960.
| Status | New | ⇒ | Closed |
| Closed_Date | 0000-00-00 00:00:00 | ⇒ | 2016-05-08 15:44:52 |
| Closed_By | ⇒ | brianteeman |
I can confirm running into this problem as well (following the same procedure as described above). It appears that the HTTP->HTTPS redirect happens during routing, after session handling/creation occurs. If a user initially logs in while force_ssl is enabled, they receive a secure cookie. If they then navigate to a non-HTTPS page, by definition, the cookie is not included in the request. They are then given a new session, overwriting the existing one, prior to the redirect to HTTPS occurring.