3

I have been researching this issue for days now. I can't find anything on the forums, WHATWG email lists, chrome blog, etc.

I write a third-party embedded app for various customers that is embedded in sites via script tag. Pretty standard stuff. There's a lot of critical functionality that implicitly requires us being able to set local/session storage values. Our app has both a "wrapper" script that runs directly on the client page, as well as an iframe that the wrapper embeds, which runs as a child frame.

We've gotten reports that our app breaks in incognito due to the fact that sessionstorage and localstorage are unavailable, which I'm able to reproduce. I understand the concept here, that these are unavailable in incognito for third party iframes - however, I thought that third party scripts still had sandboxed access to web storage in private browsing on the main page itself.

Does anyone know definitively if web storage is simply shut off/inaccessible? I wrote a cross-document messaging system to pass attempts to access localstorage off to the parent window/wrapper script, however that doesn't seem to do the trick. I still get the errors from the wrapper saying it can't access it.

I am fully aware that there is a chrome setting to turn off this behavior but that is NOT an acceptable solution. Users should not have to change browser settings to use an application.

Its no particular code. Any attempt to use window.localstorage.setItem or window.localstorage.getItem will fail, with the error Uncaught DOMException: Failed to read the 'localStorage' property from 'Window': Access is denied for this document. This is pretty standard behavior but I thought it wouldn't do this for third party scripts embedded on a site directly.

Thanks

dudewad
  • 13,215
  • 6
  • 37
  • 46
  • What errors specifically do you get? Can you post a short example code that reproduces the problem? – Joe Sep 29 '20 at 16:24
  • Updated my comment. – dudewad Sep 29 '20 at 16:43
  • related? https://stackoverflow.com/questions/63195318/domexception-failed-to-read-the-localstorage-property-from-window-in-chrom – Joe Sep 29 '20 at 17:03
  • Already saw this, that's the third-party cookies setting I mentioned that is not an acceptable solution unfortunately – dudewad Sep 29 '20 at 18:27
  • understood. just wondering if it accurately described the same issue. – Joe Sep 29 '20 at 18:29
  • Technically it is, but the solution is sort of from the opposite perspective. That solution is kind of for "how do I personally fix this issue" vs "how do I as a developer make my application function in incognito so my user doesn't have to do it" – dudewad Sep 29 '20 at 20:32
  • Did you find anything? Similarly, we want to nest a third party web app inside another web app using an iframe. For the nested app to work, it requires access access to it's own browser storage. The nested app cannot read or write to browser storage. I am uncertain if this is desired behaviour or if we are doing something wrong. – Jens Frandsen Aug 31 '22 at 13:58
  • @JensFrandsen A colleague of mine found a way around this after we had re-prioritized to another set of work. I'll see if I can figure out what he had done and I'll update this if I'm able to get around to it - we have it working now. – dudewad Aug 31 '22 at 18:53
  • @dudewad - that'd be great. For now we're using a separate window tab. – Jens Frandsen Sep 08 '22 at 14:25

0 Answers0