Error thrown when access to LocalStorage is denied for the document.

[robke007]

Describe the bug
Our application gets loaded within an iFrame and when the application is loaded within a private browser session (Chrome Incognito Mode) we see an error indicating the 'localStorage' property from 'Window' is denied access.

This makes sense due to chrome's security policy, and since the domains differ local or session storage is not accessible within the private mode.

Our app set up a custom AuthStorage service to fix the main problem but it seems that oauth-service.ts still explicitly checks for local storage to support an IE issue, AFTER the custom storage implementation is set up.

To Reproduce
Steps to reproduce the behavior:

1. Visit an app that uses the lib within an iframe where the host page has a different domain.

Expected behavior
The feature detection of localStorage should not throw an exception.

Proposed fix
When checking if typeof localStorage !== 'undefined', the code should wrap the block of code within a try > catch to eat the thrown exception.

Desktop (please complete the following information):

• OS: MacOS
• Browser: Chrome Incognito Mode
• Version [e.g. 22] v93

Thanks!!

[jeroenheijmans]

Thx for reporting, sorry to hear you're running into an issue. :'(

Would you perhaps agree that #1087 is the same issue?

[robke007]

Yes, it seems to be the same result. I do want to add that the scenario of running an app in Incognito mode is less of an edge case than someone disabling all cookies.

[jeroenheijmans]

I would agree, except that I think I see different behavior? When I open Chrome latest on Windows 10 with the "Block 3rd party cookies" checkbox checked, and ask for window['localStorage'], I do not get the error you mention. But this:

Then again I realize that my quick test might not be representative of using this library in Incognito mode?

Either way, I think it would be good if you add your thoughts/details with a link to this issue, to the other one, and we then close this one. So we can avoid spreading the conversation of the same bug too much?

[suncastor]

Hi! Looks like there is an opened pull-request to resolve this issue.
#1105

[robke007]

@jeroenheijmans I think it's because my scenario runs our app within an iframe that has a different domain, thus the third party. #1105 mentioned the same usage with the iframe as well.

@suncastor Do we have any idea on ETA on when this could make it into a release?

Thanks for the quick replies!

[suncastor]

@robke007 unfortunately I have no idea, we do not have access rights to merge PR.

[manfredsteyer]

Thanks to this PR this issue should already be resolved.

[manfredsteyer]

Big thanks for this PR!!