Cart Loses Contents During Checkout

I have seen sporadic cases where cart contents would be lost during checkout, but am now able to reliably reproduce the circumstances (tested in Chrome/Linux on 4.14.3 SP1, but can verify it happens on earlier versions of the cart and different browsers):

1. Right-click to inspect element on checkout page (or use your preferred method to access device emulator)

2. Change the emulated dimensions to reflect a different device

3. Reload page

Anytime steps 2 & 3 are repeated (a different device is selected), the checkout "forgets" the items in cart. I've noticed a high correlation with "inspect element" and cart contents being lost, but the above steps seem to cause the issue 100% of the time.

Admittedly, this is an apparent edge case, but it's possible the underlying reason may have a larger impact than just developers testing the cart.

I have seen sporadic cases where cart contents would be lost during checkout, but am now able to reliably reproduce the circumstances (tested in Chrome/Linux on 4.14.3 SP1, but can verify it happens on earlier versions of the cart and different browsers):

1. Right-click to inspect element on checkout page (or use your preferred method to access device emulator)

2. Change the emulated dimensions to reflect a different device

3. Reload page

Anytime steps 2 & 3 are repeated (a different device is selected), the checkout "forgets" the items in cart. I've noticed a high correlation with "inspect element" and cart contents being lost, but the above steps seem to cause the issue 100% of the time.

Admittedly, this is an apparent edge case, but it's possible the underlying reason may have a larger impact than just developers testing the cart.

Hello!

This is the default behavior. Since enabling emulator changes the User-Agent sent by the browser and because by default CS-Cart links session ID with user-agent, session is being changed and cart becomes empty.

You can disable linking of user-agent to session, by commenting the following line of the code in the config.php file:

define('SESS_VALIDATE_UA', true); // link session ID with user-agent

Please note, that this file will be restored after upgrade and you will need to apply the changes again.

I hope it will help you.

Thank you for the info. It looks like that config setting has been around for a long time. In 2022 with the frequent auto-updating of browsers with resultant UA string change, is a default of true still a good idea? Privacy-centric browsers apparently aren't even sending a useful UA string anymore.

I cannot imagine a bot changing its UA string (or even a reason for it to do so). Is there some form of attack that keeping the default true protects against?

Thank you for the info. It looks like that config setting has been around for a long time. In 2022 with the frequent auto-updating of browsers with resultant UA string change, is a default of true still a good idea? Privacy-centric browsers apparently aren't even sending a useful UA string anymore.

I cannot imagine a bot changing its UA string (or even a reason for it to do so). Is there some form of attack that keeping the default true protects against?

Currently we prefer security over convenience, so this flag is enabled by default.

It is not about bots, but about possible cookie stealing. Cookie without User-Agent will be useless in this case.

Hope this explains the situation.