LocalStorage does not syncronize with local file origins
Categories
(Core :: Storage: localStorage & sessionStorage, defect)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox-esr78 | --- | unaffected |
| firefox-esr91 | --- | unaffected |
| firefox92 | --- | wontfix |
| firefox93 | --- | wontfix |
| firefox94 | --- | wontfix |
People
(Reporter: todoosincorporatedinfo, Unassigned)
References
(Regression)
Details
(Keywords: regression)
Attachments
(1 file)
|
10.71 KB,
image/png
|
Details |
item1.PNG
User Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:92.0) Gecko/20100101 Firefox/92.0
Steps to reproduce:
Create 2 Web Pages that utilize LocalStorage and enter an Item into one
Actual results:
Local Storage does not load items between pages
Expected results:
The Item should have appeared across both pages
|
||
Comment 1•3 years ago
|
||
The Bugbug bot thinks this bug should belong to the 'Core::Storage: localStorage & sessionStorage' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.
|
||
Comment 2•3 years ago
|
||
Hi John, can you please provide a complete example with code on how those pages were created and how they use storage?
And please check, if "dom.storage.next_gen" is set to true in about:config.
It would be also super-helpful if you can check if this happens with a fresh install (new profile), even better if you do this with the latest nightly version.
If the error persists it would be great to get some log. You can send them directly to me via mail (please be aware that log-files can contain private information like the URLs you visited).
Hi Jens,
I have the same problem and it is easy to reproduce.
Just create two html files local on your PC in the same folder.
- File:
<!DOCTYPE html>
<html lang="de">
<script>
localStorage.setItem('test', 'testtext')
</script>
</html>
- File:
<!DOCTYPE html>
<html lang="de">
<script>
alert(localStorage.getItem('test'))
</script>
</html>
Open File 1 and afterwards File 2. In older versions and other Browsers you get a message with 'testtext' in 92.0 the message is 'null'.
|
|
||
Comment 4•3 years ago
•
|
||
OK, so here we have local files as origins. In that case, Firefox by default treats each distinct file URL (distinct except for anchors or parameters) as a new origin, thus they cannot share local storage. This is governed by the security.fileuri.strict_origin_policy preference, which is true by default for a very long time now (at least since 3.6, it seems, see bug 539050).
|
|
||
Updated•3 years ago
|
|
|
||
Comment 6•3 years ago
|
||
The change in behavior here was intentional, local storage was the last storage type that did interpret this at folder and not file level until we landed bug 1599979 now (which was active in Nightly and early Beta for years).
If you can elaborate on your use case this might help us to understand better the impact. If it is for your own, local usage, you can easily switch security.fileuri.strict_origin_policy and/or dom.storage.next_gen to false. Though we would always recommend to set up a little web server even for small projects, the behavior of file URIs differs in many ways from "real" origins, not only wrt storage.
Other browsers such as Edge, Chrome, Opera behave as Firefox did before version 92.
I’m very ignorant of these security issues but it seems strange to me that accessing my own files through a local server rather than directly would change anything.
Changing the security setting does seem dangerous to me as it opens many possibilities that us naive uses don’t know about. Perhaps another parameter could be set up to allow local sharing without affecting anything else.
|
||
Comment 8•3 years ago
|
||
Note that this isn't supposed to work in Chromium either, see https://bugs.chromium.org/p/chromium/issues/detail?id=957695. They are less secure as different parts of the browser disagree about the security boundary of file: URLs.
|
|
||
Comment 9•3 years ago
•
|
||
The general rational for this change can be found here in bug 1500453.
(In reply to dr.kral from comment #7)
Other browsers such as Edge, Chrome, Opera behave as Firefox did before version 92.
There is no standard for this particular situation, unfortunately. File URLs are somewhat underspecified. [1]. And for Chrome there is some discussion of inconsistent behavior ongoing, too. [2]
I’m very ignorant of these security issues but it seems strange to me that accessing my own files through a local server rather than directly would change anything.
Well, a web page that uses local storage uses active Javascript and expects some state to be handled. Running this locally is not the preferred way of using a modern Web-App. The implications of bug 1500453 (other files in the same folder might be affected) are valid also here. It is much healthier to assume that a user controls the content of a dedicated web server they explicitly set up on purpose rather than the content of their download folder, as an example.
Changing the security setting does seem dangerous to me as it opens many possibilities that us naive uses don’t know about.
Sure, and please do not read my previous comment 6 as a recommendation to non-expert users.
Perhaps another parameter could be set up to allow local sharing without affecting anything else.
This would still require a lot of expert knowledge by the user. Basically this pref would need to allow again access throughout the entire folder, which still sounds bad.
[1] https://url.spec.whatwg.org/#origin
[2] https://bugs.chromium.org/p/chromium/issues/detail?id=957695
|
||
Comment 10•3 years ago
|
||
Hi,
changing security.fileuri.strict_origin_policy to false helps. But we use this to have an offline sparepart-programm for our forestry machines.
For our usecase it is important to have an offline list because in the forests there is not everywhere internet especially here in germany. I had to reprogram our shopping cart when the local cookies were shut down.
I tried with 90.0 and in this version it worked, so the switch was chaned with the new update.
I won't tell our customers to change something in the config due to the danger of making mistakes. What other possibilities do I have instead of telling them to use another browser?
Regards,
Bernhard
|
|
||
Comment 11•3 years ago
|
||
It would be best if you could make the application run from http://localhost/ or http://something.localhost/ or some such. As noted above other browsers also plan to restrict file: URLs in identical manner. The way out is to stop using file: URLs for this.
|
||
Comment 12•3 years ago
|
||
changing security.fileuri.strict_origin_policy to false helps.
That's not really a supported configuration anymore. The pref was added as a transitional "escape valve" when we first made the switch and is at this point an inconsistently supported foot-gun. I just filed bug 1730535 to get rid of it
I’m very ignorant of these security issues but it seems strange to me that accessing my own files through a local server rather than directly would change anything.
If you access your files through a local server you are telling browsers "this content is explicitly the same origin". When a browser opens files on disk it doesn't know if they are meant to go together or if some of them were downloaded off the web from different places. There were documents that contained hidden code that would wait to be opened as a file: url and then try to harvest information from your computer and look for interesting files downloaded from other sites. That's what the "unique origin" change was meant to address. Sharing local storage between files perpetuated that risk.
The good news is that, compared to when we first made the strict-file-url change, launching a basic local web-server is a simple node or python command
|
||
Updated•3 years ago
|
|
|
||
Updated•3 years ago
|
|
|
||
Comment 13•3 years ago
|
||
Set release status flags based on info from the regressing bug 1599979
|
||
Updated•3 years ago
|
|
||
Updated•3 years ago
|
|
|
||
Updated•3 years ago
|
|
|
||
Comment 14•2 years ago
|
||
Based on comment 9 and comment 12 we can close this invalid.
Description
•