Closed Bug 442048 Opened 14 years ago Closed 10 years ago

chrome/components can't access secure sessionStorage items

Categories

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

defect
Not set
normal

Tracking

()

RESOLVED DUPLICATE of bug 600307

People

(Reporter: zeniko, Assigned: mayhemer)

References

()

Details

Currently the only way to access a secured sessionStorage item is from the domain it's been set (principal URI has to be https). This makes it impossible to save and restore those items from chrome or Firefox' SessionStore component as needed for bug 339445.
This is pretty much the same as 357323.
AFAICT bug 357323 is about file:// and possibly chrome:// documents having access to a sessionStorage of their own.

This bug is about the possibility to access the sessionStorage of arbitrary https? documents. It is already possible to iterate through and modify all non-secured sessionStorage items for any domain with a system principal. Under those conditions it seems somewhat inconsistent that the same isn't possible for secured sessionStorage items (in comparison to secured cookies which can be read/written arbitrarily from chrome).
Moving to DOM: Mozilla extensions, where the rest of sessionStorage bugs rest.
Component: DOM → DOM: Mozilla Extensions
Assignee: nobody → honzab.moz
Flags: blocking1.9.2?
Not blocking 1.9.2 on this.
Flags: blocking1.9.2? → blocking1.9.2-
I think this bug is invalidated with bug 495337.
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 495337
Did anyone test this?  This doesn't work in Firefox 19 and apparently never has.  Access to content.sessionStorage works for non-secure pages, but for https sites it always returns length zero even when there are sessionStorage items.  Clearly the principal changes have had an effect, but this bug still exists.

Same sort of result getting the sessionStorage directly from the principal (getSessionStorageForPrincipal()).  Returns a storage object but length is zero.

Related bug 497658 for session restore of secure storage items is still open.

I can't re-open this bug.  Can someone else do it, or explain why I'm an idiot and this is really working?
(In reply to Ian Nartowicz from comment #7)
> Did anyone test this?  This doesn't work in Firefox 19 and apparently never
> has.  Access to content.sessionStorage works for non-secure pages, but for
> https sites it always returns length zero even when there are sessionStorage
> items.  Clearly the principal changes have had an effect, but this bug still
> exists.
> 
> Same sort of result getting the sessionStorage directly from the principal
> (getSessionStorageForPrincipal()).  Returns a storage object but length is
> zero.
> 
> Related bug 497658 for session restore of secure storage items is still open.
> 
> I can't re-open this bug.  Can someone else do it, or explain why I'm an
> idiot and this is really working?


Can you test with build from this try run? 

https://tbpl.mozilla.org/?tree=Try&rev=27a6630bcafc

Thanks.
The try build works, both sessionStorage and localStorage items on https pages now appear.
Duplicate of bug: 600307
(In reply to Ian Nartowicz from comment #9)
> The try build works, both sessionStorage and localStorage items on https
> pages now appear.

Thanks for checking!
Component: DOM: Mozilla Extensions → DOM
Component: DOM → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.