Client doesn't work if third-party session storage is disabled

[asadovsky]

In Chrome (55.0.2883.95), for privacy reasons, I set "block third-party cookies and site data".

With that, the code below produces this error:

Uncaught DOMException: Failed to read the 'sessionStorage' property from 'Window': Access is denied for this document.
at x.C (https://ssl.gstatic.com/accounts/o/644096210-idpiframe.js:12:285)
at Object.k.vb (https://ssl.gstatic.com/accounts/o/644096210-idpiframe.js:8:121)
at S.h.start (https://ssl.gstatic.com/accounts/o/644096210-idpiframe.js:50:170)
at Object.Bb [as startIdpIFrame] (https://ssl.gstatic.com/accounts/o/644096210-idpiframe.js:84:713)
at https://accounts.google.com/o/oauth2/iframe:1:413

Code:

    gapi.load('client', function() {
      gapi.client.init({
        clientId: clientId,
        scope: scope
      }).then(function() {
        gapi.auth2.getAuthInstance().signIn().then(function() {
          var user = gapi.auth2.getAuthInstance().currentUser.get();
          processContacts(user.getAuthResponse()['access_token']);
        });
      });

This can be fixed by adding accounts.google.com to the exceptions list, or by allowing third-party storage wholesale, but really, this shouldn't be necessary; the client should degrade gracefully in the case where the browser doesn't allow third-party access to local storage.

[bsittler]

Thanks for reporting this issue. The issue is already known to us, but I'm not sure when or whether a fix will be available.

In the meantime, you may be able to work around this using the steps described in http://stackoverflow.com/questions/33200681/google-signin-not-working-in-safari-private-mode or something similar, although I have not tried that myself.

[mbloch]

@bsittler, I'm pretty sure that the workaround that you linked to does not help with the current issue.

(The workaround suggests replacing the #setItem() method of Storage.prototype when the browser is in private mode, because the native method throws an error, at least in Safari. The exception that @asadovsky reported above occurs when trying to access sessionStorage, i.e. before sessionStorage.setItem() could be called.)

A different workaround to avoid the "Access is denied" exception was proposed on the Chromium issue tracker (https://bugs.chromium.org/p/chromium/issues/detail?id=357625).

That workaround replaces localStorage and sessionStorage with proxy objects, using Object.defineProperty(window, 'localStorage', {value: /*your polyfill here*/ });.

This second workaround did not work for me -- the exception is still thrown. Could this be because the function that causes the error is running in an iframe, which has a different window object from the main page?

I'd appreciate any further suggestions :)

[bsittler]

Correct, this error occurs in an IFRAME on a separate origin, so a polyfill won't work. I was intending to suggest that you could test for working storage and avoid loading the library if the storage does not work.

[mbloch]

Ah, gotcha, thanks for the quick response.

[TMSCH]

@mbloch @asadovsky we released a change that allows you to gracefully degrade under such environment, please have a look at the documentation: https://developers.google.com/identity/sign-in/web/reference#googleauththenoninit-onerror.

[mjgallag]

@TMSCH do you mean gracefully degrade as in show an error message telling them they need to enable 3rd party cookies?

[TMSCH]

@mjgallag yes, as you are now able to detect the issue, you can tell them that their browser is unsupported (and list potential reasons). It's very difficult to accurately detect that 3rd party data is blocked from our library, which is why we haven't yet been able to release a proper fix.

[mjgallag]

@TMSCH got it, thanks for the quick reply!

[TMSCH]

@mjgallag you're welcome!

[internettrans]

We are experiencing this issue as well. Using the idpiframe_initialization_failed error is really helpful for us to be able to message to our users what is happening. But even if we handle the error (gapi.auth2.getAuthInstance().then(success, err => {/*handle error*/})), the gapi library still throws a javascript error, which is problematic for the following reasons:

1. What is thrown is an object, not an Error., which means there is no stacktrace associated with it. This is especially problematic for us since we log javascript errors to the server, but we don't have access to the stacktrace.
2. The object is thrown inside of a setTimeout, which means that a window.onerror handler doesn't even have access the file, line, or column of the code that threw this error. So we can't filter out all errors originating from google.com domains, because that is lost with the setTimeout.

What do you guys think of updating the library code so that it doesn't actually throw the error, but only provide the error through the getAuthInstance().then(...) error handling? Or if not that, then perhaps converting it to be a real Error object instead of a plain object?

[TMSCH]

Hi @joeldenning!
Thanks for the feedback. We actually continued to throw the error to be consistent with previous behavior, which is probably not useful anymore.
However I'd like to make sure I observe the same error when third-party data is blocked. When I reproduce it, an error is thrown from within the IFrame, not from the client window, and so I also cannot catch it (although it is an instance of Error).
Is it your case? Or is the error thrown from the main window? Also, what is the error log?
Thanks!

[time-less-ness]

Would like to report we get same behaviour as @TMSCH. We cannot catch the error. Can't implement client-side OAuth2 when user doesn't allow 3rd party cookies/storage.

[TMSCH]

Hi @philovivero ! We recently pushed a changed to not throw the error from within the IFrame. Could you test again and let me know if that works? You should not observe any JS error, but be able to catch it in the promise. Thanks!
However, chrome with 3rd party cookies/storage disabled is still unsupported.

[time-less-ness]

I'm not sure I will be able to repro. I ripped out all that code. For now we've decided to just let customers who uncheck that get failures, and when we look into it again, will likely implement OAuth2 server-side, since we assume at least some percentage of customers will be privacy-minded.