Closed Bug 494799 Opened 16 years ago Closed 16 years ago

Should DOM storage objects be mapped by an "effective script origin" rather then just an "origin"?

Categories

(Core :: DOM: Core & HTML, defect)

Product:
Core
Component:
DOM: Core & HTML
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED INVALID

People

(Reporter: mayhemer, Unassigned)

Details

Bug 494543 revealed that when a page changes document.domain it still loads sessoinStorage (and also localStorage) for the original URL's principal codebase. We should decide if it is correct or not. For instance, http://configure.us.dell.com is using sessionStorage to store to a shopping cart. Before it access sessionStorage for the first time it changes document.domain to http://dell.com. In this state we create a new sessionStorage object at the moment a page access window.sessionStorage, assign it a principal with http://dell.com domain (overriding codebase) but still map it by "http://configure.us.dell.com" origin (using nsIPrincipal.origin attrib). According to http://www.whatwg.org/specs/web-apps/current-work/#origin an "origin" is the original principal of the document, immutable, an "effective script origin" can be changed by manipulation with document.domain and its initial value is identical to an "origin" value. According to http://dev.w3.org/html5/webstorage/#the-localstorage-attribute the storage is mapped to an "origin" that means we will get the same storage object even we manipulate document.domain. That's how our implementation works at the moment. But, the security checks we do when accessing the storage object are against this approach and disallow further access to session/localStorage that was created before document.domain has changed. This was observed in bug 494543 and bug 494723. Problem is, I was trying to prove this with an automated test. I cannot reproduce by just doing {sessioStorage; document.domain = "..."; sessionStorage /*-> expected throw, but principals of storage object and of the page are identical*/;}. It seems that sessionStorage have to be cloned among windows or there is some different operation. However, I was seeing in both bugs that the accessing principal was assigned a domain different from the previous origin. I'm not sure what is happening in code of those pages. Looks like the js files from both bugs where these bugs appear are shared - almost identical. http://i.dell.com/images/global/js/s_code_dell_vh19_3.js http://www.tvguide.com/Script/s_code.js I'd like to figure out, of anyone has some suspicion please let me know. Should we propose to WHATWG/W3C to change the storage spec to use an "effective script origin"?
Flags: blocking1.9.1?
How do other globalStorage-supporting browsers behave? (Seems like we need a better component than "Mozilla Extensions" for this stuff, but "DOM: HTML5" is perhaps not a useful classification. Just "DOM", and put a slow death to the over-fine sub components?)
If someone gives me a test script to run, I can toss it against Chrome 2 and IE8 and OperaWhatever and see what it does.
Assignee: honzab.moz → nobody
Status: UNCONFIRMED → NEW
Component: DOM: Mozilla Extensions → DOM
Ever confirmed: true
<!-- loading as http://a.test.localhost/testLocalStorage/ --> <!DOCTYPE html> <html> <head> <script type="text/javascript> function test() { window.sessionStorage.key1 = "ulozena hodnota pro a.test.localhost"; document.domain = "test.localhost"; alert(window.sessionStorage.key1); } </script> </head> <body onload="test()"> <input type="button" onclick="test()" value="test"></input> </body> </html> Minefiled (trunk): I got exception on line "alert(window.sessionStorage.key1);", suddenly IE8: passes, no exceptions and alert shows the stored value CH2 and OP9.something (latest) doesn't know sessionStorage (am I doing something wrong?)
(In reply to comment #3) > Minefiled (trunk): I got exception on line > "alert(window.sessionStorage.key1);", suddenly > It's thanks call to CacheStoragePermission inside of GetItem. So, it behaves as I would actually expect.
Yeah, looks like Chrome 2 and Opera 8 don't yet support sessionStorage; strange, I would have thought that it was part of the ACID3 test.
sessionStorage is HTML5-era functionality, acid3 limited itself to 2004 or earlier. I ran into this basic question when implementing postMessage a year ago, and I assumed the choice to use the origin rather than something that could be changed by setting document.domain was intentional, to move away from document.domain as a value for use in security decisions given its complexity. It's also not clear to me that the "shape-shifting" behavior of storage objects before and after a document.domain change is intuitive or predictable for web developers. I'd rather it be that sessionStorage and its properties and values are what they are at document load time and change only when that page or others at the same origin make those changes.
Honza, have you considered raising this issue with Ian?
(In reply to comment #7) > Honza, have you considered raising this issue with Ian? Posted to WHATWG forum.
Flags: wanted1.9.1.x?
Flags: blocking1.9.1?
Flags: blocking1.9.1-
According to feedback on WHATWG forum this bug will soon become INVALID. Looks like moving with document.domain is a hack and leftover, we should not affect storage access by it.
Decided to leave the current behavior.
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → INVALID
Flags: wanted1.9.1.x?
Just for reference, the thread on WHATWG: http://www.mail-archive.com/whatwg@lists.whatwg.org/msg15044.html
Component: DOM → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.