Handle specific DOMException when dandiarchive is hosted in an iframe

[yarikoptic]

visiting https://dandiarchive.org which forwards to web ui, if page is embedded within iframe (trying to prepare for the virtual OHBM 2021 booth) leads to

Uncaught DOMException: Failed to read the 'localStorage' property from 'Window': Access is denied for this document.
    at new t (https://gui.dandiarchive.org/js/chunk-vendors.107d6d4a.js:101:59792)
    at new e (https://gui.dandiarchive.org/js/chunk-vendors.107d6d4a.js:29:55236)
    at new e (https://gui.dandiarchive.org/js/chunk-vendors.107d6d4a.js:29:58845)
    at Module.cd49 (https://gui.dandiarchive.org/js/app.83c9bcaf.js:1:12834)
    at s (https://gui.dandiarchive.org/js/app.83c9bcaf.js:1:564)
    at Object.0 (https://gui.dandiarchive.org/js/app.83c9bcaf.js:1:1562)
    at s (https://gui.dandiarchive.org/js/app.83c9bcaf.js:1:564)
    at n (https://gui.dandiarchive.org/js/app.83c9bcaf.js:1:431)
    at https://gui.dandiarchive.org/js/app.83c9bcaf.js:1:1527
    at https://gui.dandiarchive.org/js/app.83c9bcaf.js:1:1532

so the question is either we need access to the entire Window or it could be avoided?

[waxlamp]

Strangely enough, I don't see localStorage appear anywhere in the dandiarchive codebase. Do you have an idea of where that access is coming from?

[jjnesbitt]

It looks like girder-oauth-client does makes use of localStorage, which we use in the GUI for login to the API.

I'm a bit confused, what does embedding the page into an iframe accomplish?

[yarikoptic]

• dandiarchive.org redirects to web ui
• I have dandiarchive.org as the one for DANDI on https://centerforopenneuroscience.org/projects#dandi_
• my OHBM conference booth has https://centerforopenneuroscience.org/ embedded in an iframe so people visiting the "booth" can immediately visit anything pertinent and jump to projects pages (such as DANDI)

so to answer the

... what does embedding the page into an iframe accomplish?

make visitors of "my" OHBM booth be able to visit DANDI. A workaround could be to point to https://www.dandiarchive.org/ instead but still, they could get to https://gui.dandiarchive.org/#/ and get similar kaboom.

IMHO website must not crash completely under such circumstances. It is ok if site disallows some operations though (e.g. to login if localStorage is needed).

[waxlamp]

Thanks for the extra information, @yarikoptic.

Does the crash happen specifically when trying to log in? Or does it always happen upon visiting the page at all?

[yarikoptic]

That's a great question/point -- I forgot to realize that I was already logged in! so I logged out, reloaded booth page, followed the links again -- the same story. so I guess it happens regardless of either I am logged in or not -- I guess that localStorage (instead of some not-shared among "sessions") is used to check if I am logged in or not.

[waxlamp]

Then I think we can add logic that catches this condition and changes or removes the login button, since in an iframe that feature is not supported. Then the default situation is to be in "read-only mode" for new visitors. (I am not sure what the situation will be for logged-in visitors; I suspect they will also be in the same "read-only" mode.)

[yarikoptic]

sounds good to me @waxlamp , thanks!

[mvandenburgh]

I filed a PR to hide the login button when the page is in an iframe (#750).

(I am not sure what the situation will be for logged-in visitors; I suspect they will also be in the same "read-only" mode.)

Everything works as it should if a user is logged in already, so I didn't make them go into read-only mode.

[mvandenburgh]

This turned out to be an issue with third party cookies not being enabled. Once enabled, the exception no longer occurs.