Sign In
4
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.
|
|
