With browsers becoming increasingly strict regarding cookies, is there any chance to integrate localStorage as an alternative, e.g. https://www.codementor.io/@byjg/using-json-web-token-jwt-as-a-php-session-axeuqbg1m
My experience has been that localStorage is more reliably persistent, which is definitely a goal when it comes to preserving cart contents. Maybe also an opportunity to come up with a more elegant approach to anti-CSRF attacks as well?
With browsers becoming increasingly strict regarding cookies, is there any chance to integrate localStorage as an alternative, e.g. https://www.codementor.io/@byjg/using-json-web-token-jwt-as-a-php-session-axeuqbg1m
My experience has been that localStorage is more reliably persistent, which is definitely a goal when it comes to preserving cart contents. Maybe also an opportunity to come up with a more elegant approach to anti-CSRF attacks as well?
I mean, this has nothing to do with localStorage directly, for all we care JWT's can be used in cookies as well...
Yes, I see that my thoughts aren't perfectly encapsulated in the linked article, which was probably colored by previous research into options for replacing cookie-based session storage with something a bit more persistent.
The advantage with localStorage is that it provides considerably more space, to be able to do things like keep a local copy of the customer's cart contents (driven in turn by seeing cart persistence issues in the latest CS-Cart). Yes, ideally the cart code would be bulletproof so this is a non-issue, but having a redundant copy for verification seems like a good idea at this point.
Are you saying that you want to maintain cart content AFTER a user's session has expired? How are you going to accurately tie that to a user if there's no session correlation? Right now session and cart content are stored in the DB. Not sure I understand why you would want to put it in the filesystem.
Are you saying that you want to maintain cart content AFTER a user's session has expired? How are you going to accurately tie that to a user if there's no session correlation? Right now session and cart content are stored in the DB. Not sure I understand why you would want to put it in the filesystem.
With a JWT the session should theoretically never "expire", it should remain valid as long as the user has the cookie present.
Yes, I see that my thoughts aren't perfectly encapsulated in the linked article, which was probably colored by previous research into options for replacing cookie-based session storage with something a bit more persistent.
The advantage with localStorage is that it provides considerably more space, to be able to do things like keep a local copy of the customer's cart contents (driven in turn by seeing cart persistence issues in the latest CS-Cart). Yes, ideally the cart code would be bulletproof so this is a non-issue, but having a redundant copy for verification seems like a good idea at this point.
One cookie can store up to 4Kb, which is plenty for all customer data and stuff, but indeed for something variable like a cart this should not be done. The best thing to do, would be to have a separate API endpoint for the product cart and retrieve that into localStorage. This way, whenever a user e.g. logs back in, you can also repopulate the cart with what it was before the user logged out.
For the sake of verifying the JWT, you could hash the user data row, so that in case of a password or email change, you can invalidate it accordingly.
@harmsmitsdev, thanks for the feedback. If you would like to tackle this on a paid basis, PM me. I'd also be open to collaborating if it's something you have an interest in yourself.
@tbirnseth, the reason you would want to put it in the filesystem is because user carts (not sure about logged in users, but unvalidated users for sure) are getting cleared (very frequently in 4.14.1; less in 4.14.2, but not never). Bugs aside, however, sessions expire and cookies get cleared. The point is for cart contents to persist, even if session ID changes. If CS-Cart database / session has zero items, but localStorage has items, it would import localStorage items into current session (validating that the product IDs and quantities are valid of course).