I just had a customer report this on a new install of CS-Cart v4.3.2. The customer is using an Apple iPad. The shopping cart will not retain the items he adds, and viewing the cart logs him out. It sounds like a session problem.
The entire store is HTTPS, so the browser should not be defining different sessions. I will have to test this on an Apple iPad and see what if I can reproduce the problem.
I just had a customer report this on a new install of CS-Cart v4.3.2. The customer is using an Apple iPad. The shopping cart will not retain the items he adds, and viewing the cart logs him out. It sounds like a session problem.
The entire store is HTTPS, so the browser should not be defining different sessions. I will have to test this on an Apple iPad and see what if I can reproduce the problem.
What is the customer's IOS version and browser in use?
I have a customer on V4.2.3 that is also experiencing this problem but it does not seem to be limited to IOS. We have commented out the define('SESS_VALIDATE_IP', true); line in config.php with no change in results.
I have a customer on V4.2.3 that is also experiencing this problem but it does not seem to be limited to IOS. We have commented out the define('SESS_VALIDATE_IP', true); line in config.php with no change in results.
I have a customer on V4.2.3 that is also experiencing this problem but it does not seem to be limited to IOS. We have commented out the define('SESS_VALIDATE_IP', true); line in config.php with no change in results.
SESS_VALIDATE_IP was already commented out when this problem occurred.
SESS_VALIDATE_UA is active.
// Session options
// define('SESS_VALIDATE_IP', true); // link session ID with ip address
define('SESS_VALIDATE_UA', true); // link session ID with user-agent
This has been an ongoing problem for years. It's been posted several times to bugtracker and to helpdesk always with a response like "can't recreate". If it was reproducible on demand, then I'd be happy to diagnose it. It's like the "undefined index" error that comes from Session.php. No one knows how to recreate it on demand to debug/diagnose it.
A bit of history.... It became most obvious when IE 7 came out and tried to predict the best User Agent for a customer to use to view a specific page. Hence it would change the UA from 7 to 6 or 9 to 8, etc. This caused the session to "reset". Commenting out the UA define addressed this specific issue, but it did open a hole. Other browsers also then started doing the same thing and as mobile became more dominate, the problem increased.