-
Notifications
You must be signed in to change notification settings - Fork 9.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
local/session storage is mismanaged, particularly when it doesn't exist #16568
Comments
Hi @dan-ding. Thank you for your report.
Please make sure that the issue is reproducible on the vanilla Magento instance following Steps to reproduce. To deploy vanilla Magento instance on our environment, please, add a comment to the issue:
where @dan-ding do you confirm that you was able to reproduce the issue on vanilla Magento instance following steps to reproduce?
|
ya, any version of magento should do. start with 2.2.0! |
This is not a valid case. Additional safeguard should be added probably similar to the one appearing when JavaScript is disabled. |
@orlangur whhhaaa? come on. it's totally valid. (a) comparing it to having javascript disabled makes as little sense as saying people can only use IE 10. |
What do you need to give this some deeper consideration? |
They should be determined. It is obvious that with local storage disabled Magento will not function properly, check https://devdocs.magento.com/guides/v2.2/extension-dev-guide/cache/page-caching/private-content.html for instance. |
Ok! Discussion -- That page doesn't say localstorage is required, it just says magento uses it ( and forget for a moment how silly storing someones name or address or viewed products in localstorage actually is). However, if one is going to use it, one of big decisions and case(s) to test, is going to be what to do when it's not available. To that last item, it's not obvious magento won't work if localstorage isn't available. Take the library (that is part of the core) to manage this so-called localstorage: And that unfortunately brings us to this issue because how magento "uses localstorage", it ends up being just a matter of time before some customers are paralyzed. Either by too many cookies, or too large of a request header. Can we move forward now? |
This is totally not silly, please try to be more constructive. What would you suggest to use for fallback instead of cookies when local storage is not available for some reason?
I can say you more, you cannot turn this mechanism off. I do agree that it looks like cookies storage as fallback simply does not work. What is the % of users having local storage disabled? |
Hi @orlangur on our website some customers also have this issue - OS: Android (including 7.1.1, that is quite new) + opened website in Facebook (in app) - as result - no local storage support. Probably the same issue will be with twitter/another apps Another example: Incognito mode on Safari iOS/MacOS - no local storage support. As a workaround I we could NOT use cookies as fallback from localstorage |
@ihor-sviziev no objections from my side if it would allow a decent UX. Considered it by myself but I don't think doing request for section data on each request is acceptable especially on mobile devices. If UX is poor, we can show warning to open site in a proper browser. @dan-ding could you please play with such variant really quick? Just comment out fallback you already found in code and check how it works with disabled local storage. |
I'm sorry, @orlangur, I am being constructive (to the ends of having a better application) . Storing a customers name in localstorage is silly. I'd open up an issue for it, but I don't know where would get the consideration it deserves. I'm confused. You've rebuffed the issue twice saying in so many words it's not an issue, now you're asking me questions as if you think it is an issue. |
And I firmly object to:
That is poor UX. And I have no idea what percentage of customers do what with their browsers. I do know that I see, or hear about, symptoms of this issue almost hourly, which has been slowly increasing over the year. |
It means only that you know nothing about FPC in Magento :) I never said this is not an issue. Just that there are multiple approaches to circumvent this situation:
|
Haha so silly @orlangur Yeah, you're right, I know nothing about magento or fpc. Geez, I was going to suggest
How dumb is that idea, right?! |
@dan-ding it's the same as
And I just suggested you to check how usable will be Magento with such removal. |
NO it's not the same. I ... I ... @orlangur this is a ridiculous conversation which you seem incapable, and why I closed the ticket. You want to experiment, then YOU do it. Geezz, you want to talk about adding buggery code to show warnings or other nonsense -- yet that already exists in magento 😱 (and thankfully it can still be turned off). For anyone else getting a headache reading this, AND with cookie issues or customers sessions being lost the following may help some: search and replace these strings in: change this will make the cookies be reused instead of regenerating themselves with random names and various paths. it could be more clever, but ... there may be other issues (private browsing in safari possibly?) with this library since it's four years old and unmaintained, but I'll let someone else open that issue. |
Essentially, users carts will disappear or they won't be able to login, or they'll be logged out or some other session related wackyiness.
creating here from #7931 as @orlangur said to make a new one
There are multiple reasons why this is occurring -- the follow is the first way I've found to recreate an a problem easily.
https://github.com/julien-maurel/jQuery-Storage-API/blob/d2ce10b0fb53d7cb919f14e70853a5c232477f93/jquery.storageapi.js#L423
Preconditions
Steps to reproduce
One way to reproduce is:
Expected result
Actual result
customers are unhappy
clients are really unhappy
cookies are a sogging mess
depending on surfing habits there will be multiple ss_\d{8}* named cookies and multiple ls* cookies, possibly far too many depending on a variety of normal operating conditions.
possibly get a "too many cookies" error
possibly get a "request header too large" error
changing
https://github.com/julien-maurel/jQuery-Storage-API/blob/d2ce10b0fb53d7cb919f14e70853a5c232477f93/jquery.storageapi.js#L423
to be a static string instead of a random number for the window.name helps with the ss_* cookies
it will not help with the ls_* cookies
again, disabling localstorage here in firefox is just one example of causing the issue
The text was updated successfully, but these errors were encountered: