Over the past several weeks I have been working with a client on a problem where users would mysteriously have their cart become empty or be in the middle of the checkout process and suddenly the cart would be empty and the checkout would abort.
We applied a “fix” from the helpdesk which did not help at all.
We noticed that the majority of problems were coming from users who were using IE8 or IE9, but occasionally other browsers too (most notably phone based browsers).
After heavy logging of the class Session code, we identified the issue as browsers going into compatibility mode based on either the DOCTYPE they were seeing or some html or other “indicator” that they needed to switch to be compatible.
Cs-cart uses the IP address and the User-agent to validate a session. I.e. if a user tries to open a session where the IP address or the User-agent has changed, it will regenerate the session causing the old one to be empty.
For some reason they have turned of IP validation of the session in config.php (commented out in 2.2.4). I’m assuming it’s due to twigmo or problems with changes in IP address of mobile devices. But comparison of the last used User-agent and the User-agent reported by the current connection was still performed.
So you’d see a User-agent change from IE-9 to IE-7 (compatibility mode) or from IE-8 to IE-7 and even sometimes from IE-9 to IE-8. And very rarely I observed a change from IE-7 to IE-6.
Whether users are clicking the compatibility button or whether the browsers are doing this automatically, I don’t know.
The easiest solution (but the least secure) is to change the line is config.php from
define(‘SESS_VALIDATE_UA’, true); // link session ID with user-agent
to
define(‘SESS_VALIDATE_UA’, false); // link session ID with user-agent
But with IP validation turned off this offers NO session validation at all.
We implemented a limited solution where a check is done before the session validation occurs as to whether the browser is IE-7,8 or 9 and whether it is changing to IE-7, 8 or 9. If that is true then we use the new User-agent so when the compare is done, they come out equivalent and the session is not regenerated.
I can’t post the code here without the client’s permission since they’ve paid for the hours to track it down and develop the solution. But I wanted to let folks know what the problem is and how it can be addressed.
If the client gives me permission, I will post the solution as an update.
If you want to test this on your own site, use IE-9 and add something to your cart. Then go click the compatibility button in the address bar and go to a page, then back to your cart. It will be empty.
So bottom line is that session validation has been whittled away to being almost non-existent with the advent of mobile devices and the compatibility mode of all major browsers. Going to have to come up with a different way of avoiding a hijacked session.
Switching compatibility mode in MSIE 8/9 does result in cart contents being lost.
MSIE8 has Trident/4.0 layout engine included in User Agent. So MSIE8 operating in Compatibility mode (MSIE7) still reports Trident/4.0
MSIE9 has Trident/5.0 layout engine included in User Agent. So MSIE9 operating in Compatibility mode (MSIE7) still reports Trident/5.0
I assume you are doing some kind of check on the user agent for compatibility mode as follows:-
if user agent string contains “MSIE 7.0” then
if user agent string contains “Trident/4.0” then browser is MSIE 8 in compatibility mode
else if user agent string contains “Trident/5.0” then browser is MSIE 9 in compatibility mode
I don't check for Trident. I tried to keep it simple in that I look if the agent has MSIE 9,MSIE 8 or MSIE 7 in the stored user agent string and the current user agent string contains one of the same, I set the stored user-agent to the new user-agent so the compare (within the cs-cart distributed code) will compare equivalent and NOT cause a session to be regenerated.
Edit: Note that other browsers will have the same issue if they are switched to a different user-agent (which most can be with addons now) during a particular session. Hence cart contents will be lost (as well as other session data) if that occurs.
I think this is happening on my site. In looking at yesterday's logs, I saw 3 customers who went so far as to enter all of their info, but did not complete checkout. In looking more closely at their “visitor path”, I noticed that 2 of them went to the checkout.cart page, then to checkout.checkout and then they are returned to checkout cart. Sometimes, they will do this 2 or 3 times before they eventually give up and leave the site. I am doing the one-page checkout now, but I was using the multi-page checkout up until a few weeks ago and it seems to happen with both methods. The good thing about the one page checkout is that when the error occurs, the customer has entered some of their information, so I can try to contact them and help them finish the order. Can you please help me to fix this issue?? It is definitely hurting sales…
Thanks!
Jennifer
This is an interesting thread. Why would this not be considered a bug? Am I not understanding this thread correctly?
If browsers as recent as IE 8 and 9 are having this issue, this seems like it would be a major bug.
We do have customers who call us and say they try to order but “have problems” or “can't get our site to work” but we didn't really think much of it because we have many “seasoned” folks who order our products and often struggle with a computer anyway.
With compatibility switched on this also creates a huge gap around any file upload option either on content or product pages on my site.
image attached
Easist “fix” is to comment out this line in config.php Change
define('SESS_VALIDATE_UA', true); // link session ID with user-agent
to
//define('SESS_VALIDATE_UA', true); // link session ID with user-agent
But do note that this will eliminate all session hijacking defenses on the system. So, in doing this, you need to understand that you are allowing your system to be more vulnerable to a session highjack than before.
My personal opionion is that the risk of session hijacking is much much lower than the impact to customers who are using current browser technologies.
You will note that the IP Validation has been disabled by default by cs-cart and I'm assuming that it caused problems with Twigmo or other mobile environments where the user's IP address can change based on their current location.
Thanks Tony, also dunno if I missed it and others have commented or not but I tested this on CS Cart demo site today and same thing happens, cart empties.
john
[quote name='tbirnseth' timestamp='1337632336' post='136934']
Easist “fix” is to comment out this line in config.php…
[/quote]
This may be an okay temporary fix, but again, shouldn't this be addressed as a bug with CS-Cart? If our sites do not work properly with IE8/9 then that is a HUGE problem.
According to MSDN…
[quote]
…What you may not know is that Microsoft is going to include a pre-canned list of web sites that will auto-render certain web sites in Compatibility View with no user intervention…
[/quote]
So if IE automatically uses this “Compatibility View”, then would we be able to enter the code found at…
http://www.mat-wrigh…lity-quick.html
…under the title of, “Your website isn't IE9 Compatible” and basically just tell the IE9 browser to use one specific version like “emulate IE8”?
Here is a sample from their site but it has NOT been used and I have NOT tried it!
Would this stop IE9 or 8 from trying to automatically “fix” the site and then make the customer loose their information?
duplicate
I would expect that it would.
It took a long time to narrow this one down to what was happening.
Think someone is going to have to come up with a better way to detect/prevent hijacked sessions. IP would have been the best but since cs-cart has not commented in this thread as to why they commented it out, uncommenting it could have unknown results.
I thought I had reported it as a bug and it's been reported under the symptom a couple of times with various fixes that don't really work.
[quote]
So if IE automatically uses this “Compatibility View”, then would we be able to enter the code found at…
http://www.mat-wrigh…lity-quick.html
[/quote]
I am not, under any circumstances, going to try to figure out what MS does and why and predict what they will try to do tomorrow. The fact that ALL the browsers now allow the user to change the user-agent at any time will cause the session to be restarted and the prior session data (login, cart, etc.) will be thrown away.
I guess I wasn't clear on my point, which is that comparing the user-agent string from the last access to the current access is probably no longer a good indicator of a session hijack attempt. Since cs-cart has taken IP out of the equation (I'm guessing due to Twigmo and other mobile issues) that detecting session hijack is no longer a viable thing to do unless some other criteria than IP and/or user-agent string is used to detect it.
I posted this as a bug using the original post from Tony in bug tracker to see if we can get a response from CS-Cart. You can view it at…
http://forum.cs-cart.com/tracker/issue-3152-cart-emptying-or-checkout-reporting-cart-is-empty/
I have confirmed this issue with CS-Cart 3.0.1, so the issue does not look like it is fixed in the latest version. If you can confirm it too please be sure to visit the bug tracker link above and click on the “yes” button to let them know that others have the same issue.
we recently upgraded from version 2.0.12 to 2.2.4 and have this issue as well. we have only tested this on windows xp running ie8, even cs-cart's demo site has this issue. if we where to comment out the line of code in the config.php file as suggetsed what implication would this have on the site?
actually just checked the config.php file and that line of code was already commented out and problem still there…
Standard 2.2.4 does not have the SESS_VALIDATE_UA line commented out. It does have the SESS_VALIDATE line commented out.
It has no affect on the cart other than to NOT validate the User-agent as part of the session hijack detection. With both llines commented out, there is effectively no session hijack detection enabled.
both the SESS_VALIDATE_UA and SESS_VALIDATE lines are commented out and problem still exists
i contacted cs-cart about it and there answer was to say it's just a browser issue but thats obviously not the case
hopefully we can get a resolution on this as the problem is still there even on the latest release cs-cart 3.0
If both of those lines are commented out, then I would assume you have an issue that is different than what I described in the original posting. I'm sure there can be many causes. This was just the one that I found that related to the sessions being reset/restarted.
I am having the same problem recently and it also seems to be affecting contact and log in forms using the captcha code.
I haven't been able to get a response from support about this so I am glad I found this thread.
I'll try the config solution for now in the hope a proper fix comes along soon.