[Session (?)] Problem with login if login.php is first SSL call

[tyrion]

Hello, I believe this is my first post here. I am reporting this as bug, not knowing 100% that it is actually a bug in the OSCMax software. OSCMax version is 2.5.x:

Users of the site in question reported problems that they are unable to log on to their accounts. After a few attempts I was able to reproduce the problem. The problem occurs whenever someone tries to log in without having previously been on another SSL page of the site.

In other words, if someone goes to the homepage, then clicks directly on the "My Account" link to log in, enters email and password and submits, the login page would just reload WITHOUT successful login (and without displaying any error message). However, simply by going to a different page of the site in between, then returning to the login page, already circumvents the issue. The user would then be able to login without problem.

The issue seems to be related to the PHP session and the first SSL page someone calls. If this is an SSL page other than login.php (for example calling the shopping cart page without being logged in), the user would again be able to login without problem afterwards because the login page is not the first SSL page called.

In this connection I also noticed something in the URL in the address bar. The first SSL call has the session ID attached to the URL. For example if this is the login page, it would be:

/login.php?osCsid=b5d633533836353c722d394db6901238

If this is the case, the login will fail. The next page called after that has then still the session ID attached, for example for the homepage:

index.php?osCsid=b5d633533836353c722d394db6901238

But if I return from there to the login page, the session ID will be gone from the tail of the URL (just "login.php") and the login will work.

The session ID is ALWAYS attached to the first SSL page called, no matter which one and is also always attached to the page loaded after that, but not to the third page.

Has anyone run into this problem, does anyone know the actual cause for it, or does anyone have already a solution for the problem?

I have a couple of ideas how I could possibly "duct-tape" the issue but would prefer a more thorough and "clean" solution. Thanks in advance for any help.

[michael_s]

Seems like an issue on your site only, as I cannot reproduce it on shop.oscmax.com.

Feel free to try to reproduce the issue there. If you can, please post the exact steps to do it.

[tyrion]

Seems like an issue on your site only, as I cannot reproduce it on shop.oscmax.com.

Feel free to try to reproduce the issue there. If you can, please post the exact steps to do it.

Thank you for your response.

I created an account on shop.oscmax.com, and I was able to reproduce the issue exactly like it happens on the site in question (not "my" site, btw., it's the site for a client, I am just doing the development).

Here the exact steps:

1. Make sure to close your browser window so you don't have any old/active/stored sessions, don't open any other pages of the OSCMax site in additional tabs, the OSCMax store should be the only open browser tab.

2. Go directly to The osCmax Store - Official osCmax Products and Services

3. Click on the "Account" tab at the top. The URL displayed in the address bar should look like this:
https://shop.oscmax.com/login.php?os...4#.UFygi1HNgcs
(obviously with a different session ID, but the session ID will be attached to the file name)

4. Now try directly to login. You will find that the page simply reloads after you click the "Login" button. You can do this repeatedly, the page always just reloads displaying the login form, without a successful login.

5. Now go to the shop homepage by clicking on the OSCMax logo at the top. You should get an URL resembling the following:
The osCmax Store - Official osCmax Products and Services
Means, the session ID is still attached to the file name.

6 From here, click again on the "Account" tab at the top. Now the session ID is gone from the URL and it looks like this:
https://shop.oscmax.com/login.php#.UFyhuVHNgcs

7. Try to log in now, and the login will work.


Additional notes/information:
It took me quite a while to reproduce the issue myself after reports of the problem were brought to my attention. As developers we usually do not use websites in the same way the standard user does. Before, I probably always had already clicked around on the site before logging on to the account, or I was logged in at the admin site (I haven't checked in how far this interferes with the problem). Be that as it may, the issue manifests itself as problem probably only for a minority of the users, as many others may also click around on the site prior to logging in. However in particular long-standing, returning customers who know exactly that they are going to buy something, these may be the ones going directly to the login page and then run into the issue.

The site has more than 10,000 registered customers, in average they get maybe 1 or 2 reports per day about this problem, or so they told me. These customers then make their orders by phone or email and the business/revenue is not lost. However, there may be a few more who do not report the problem and their revenue IS lost.

The site had originally an OSCommerce system (V 2.2 I believe). I made the transition to OSCMax (specific request by the client, btw) and that (the DB transfer) worked without problem. That was done a couple months ago and the site also migrated to a new server. That's why I thought that you saying that it might be a server or environment related problem has merit, but as I was able to reproduce the issue also on your site I believe it to be a general issue.

I don't post the link to the site as I am new here and not sure in how far this is permitted/appreciated in the bug report section. I will post the link upon request, but again, I believe this to be a more general problem.

Thanks again for looking into this.

[michael_s]

Thanks for the detailed report. I have confirmed the issue is present.

A quick workaround is to set "Force Cookies" to true in the admin "Sessions" section. Of course if you are using shared ssl, you cannot force cookies. But if you are using a private SSL certificate, turn this on and the problem is cleared up.

It appears that there is a problem with either the session storing in mysql or files (not cookies) where it is not getting updated until you load another non-ssl page.