Login with SSL and Recreate Session (1.3.7)

[CJPinder]

Hi,

On v1.3.7, if a site has a dedicated SSL cert, SSL enabled for login and Recreate Session set to True then login can stop working. To fix (without having to turn off Recreate Session) change line 105 of \includes\modules\pages\login\header_php.php from

zen_redirect(zen_href_link(FILENAME_DEFAULT)); 

...to...

zen_redirect(zen_href_link(FILENAME_DEFAULT,'',$request_type)); 

Sorry this is a bit brief but I've got some kind of viral thing and a long explanation will hurt my head It's all to do with trying to redirect from a SSL page to a non-SSL page and zen_redirect changing it back to a SSL page but zen_href_link thinking you're going from SSL to non-SSL and putting the old zenid in the URL (or something like that).

TTFN
Christian.
P.S. The zen_session_recreate() needs cleaning up.

[DrByte]

1. zen_href_link already auto-detects if the $request_type is ssl or not if you don't specify the parameter, largely defaulting to off in most cases.

What hosting configuration are you working with in order for this to be a challenge?

2. What 'cleanup' are you speaking of in zen_session_recreate()?
The v1.4 code has been fully rewritten, but 1.4 is still in development and not ready for release. What specific concerns are you thinking need to be addressed and why?

[CJPinder]

Hi,

Please bear with me and I will try to explain in a bit more detail.

1. zen_href_link already auto-detects if the $request_type is ssl or not if you don't specify the parameter, largely defaulting to off in most cases.

If the $connection parameter is not specified in zen_href_link it is defaulted to "NONSSL" in all cases. Later in the code it checks whether you want to go from a SSL page to a NONSSL page and appends the zenid if this is the case.

zen_redirect will not let you redirect from a SSL page to a NONSSL page. If you try it changes the URL you provide into a HTTPS one.

So if you have your login page using SSL then the code that says...

zen_redirect(zen_href_link(FILENAME_DEFAULT)) 

...does the following...
1. zen_href_link creates a link to a NONSSL page and attaches the zenid because it thinks you are going from a SSL page to a NONSSL page.
2. zen_redirect detects that you are trying to go from a SSL page to a NONSSL page and changes the link to be a SSL one.

If you add into the mix the regeneration of the zenid then what can happen is that zen_href_link adds the old zenid to the URL rather than the new one. Note that this is only an issue with a dedicated SSL cert because zen_recreate_session does nothing if you are using a shared SSL cert.

What hosting configuration are you working with in order for this to be a challenge?

I've personally seen it on Zen Cart v1.3.7, running on PHP 4.4.2 on an Apache server with a dedicated SSL cert. User goes straight to the front page of the site, clicks the login link and logs in. A new zenid is created and a cookie set but the user is redirect back to the main page with the old zenid in the URL. The user then appears to have not been logged in and no error message is given. The issue has been reported on the forums numerous times over the past year and the usual answer is "turn off recreate session, it is a hosting issue". It is not really a hosting issue, recreate session is doing it's job and regenerating the zenid. The problem is with the logic Zen Cart uses for moving between SSL and non-SSL pages.

2. What 'cleanup' are you speaking of in zen_session_recreate()?
The v1.4 code has been fully rewritten, but 1.4 is still in development and not ready for release. What specific concerns are you thinking need to be addressed and why?

The code currently looks like this...

      if ($http_domain == $https_domain) {
      $saveSession = $_SESSION;
      $oldSessID = session_id();
      session_regenerate_id();
      $newSessID = session_id();
      session_id($oldSessID);
      session_id($newSessID);
      if (STORE_SESSIONS == 'db') {
        session_set_save_handler('_sess_open', '_sess_close', '_sess_read', '_sess_write', '_sess_destroy', '_sess_gc');
      }
      session_start();
      $_SESSION = $saveSession;
      whos_online_session_recreate($oldSessID, $newSessID);
    } else { 

As it stands, most of that code is unnecessary and code be done with...

      if ($http_domain == $https_domain) {
      $oldSessID = session_id();
      session_regenerate_id();
      $newSessID = session_id();
      whos_online_session_recreate($oldSessID, $newSessID);
    } 

I suspect that there was originally a session_destroy() in there that was either removed on purpose or accidentally. Without the session_destroy() most of the current code is not needed. The check for $http_domain == $https_domain is interesting too. It basically means that sessions are not recreated if you are using a shared SSL cert. Possibly this is because of cookie issues on different domains but isn't that what all the passing of the zenid between SSL and non-SSL pages is to get around? Maybe someone was testing the login code with a shared SSL cert, found the issue described above and fixed it by just not recreating the session.

I hope that helps.
Regards,
Christian.