Safari 11 "prevent cross-site tracking" breaking google sign-in for websites

[duncanmcdowell]

It would appear that this Safari 11 "feature" is preventing this library from determining user identity when they return to my site. Before, gapi.auth2.init would return true for googleUser.currentUser.get().isSignedIn() (assuming the user is signed in and has already accepted the auth flow). Now, no signed-in user is returned, and worse, when going through 'signIn()', no values are returned.

Cross posted to stack overflow here

[TMSCH]

Hi @duncanmcdowell, thanks for reporting this issue. I have a couple more questions as I can't reproduce it myself on my setup (I cannot upgrade to High Sierra right now).

Does this issue happen if you:

1. Open the page, sign in the user
2. Close the page.
3. In the same browser, open the page again

? Or do you need some time (>24hrs) between 2. and 3.?

Is there any console logs (errors)? when doing 1. or 3.?

[duncanmcdowell]

@TMSCH my apologies for not getting back to this sooner as I was away.

For the steps 1 thru 3, yes that will replicate the issue. As far as I can tell it is not necessary to wait any extended duration of time.

There are no console errors.

I can replicate the same issue when trying to write a review for a business from Google search results. A modal asks me to sign in to google to continue. After doing so, I see the same behaviour as I am experiencing in my own application: the authentication process begins by launching a small window/modal, and then silently fails. As expected, if I turn off the Safari option to "prevent cross-site tracking", I am able to sign in and write a review.

[TMSCH]

Thanks for the further details @duncanmcdowell. We are investigating the behavior as to decide on the best course of action.

[peprasetya]

I want to add this, as I have issue after I upgrade to iOS 11 and High Sierra.

I use gapi.signin2.render, when the browser only have 1 account to login, the onfailure is fired instead onsuccess. After the 'success' login (without the onsuccess being fired), clicking the Login button will open the login window again but then automatically close with onfailure being fired again.

I could make turn-around for my self, as I login to gmail, then add another account. So at least 2 Google Account login on the browser (mobile safari and desktop safari). Then the problem are all gone.

[TMSCH]

Thanks @peprasetya for the report. Intelligent Tracking Prevention doesn't play nicely at all with Single Sign-On services (see here) and we're trying to find the best solution.

[duncanmcdowell]

Any updates on this? I’m looking to roll out an app soon that relies on using google auth. I’d prefer not to ask Safari users to switch browsers

[TMSCH]

@duncanmcdowell the limitations are at the browser level, and cookies are required in the context of our library to securely authenticate the user. There's no way to work around the issue without asking the user to sign in again. If Google Auth is only used in your context to authenticate users (and you're not using it to authorize users) you could use cookies on your own domain to track the user's session state.

[razor-1]

is there a plan to leverage https://webkit.org/blog/8124/introducing-storage-access-api/ in google sign in?

[onyxblade]

I don't know if it is the case.
ITP blocks 307 redirections from getting correct cookies, but meta refresh is still capable to access to the cookies. This could be a workround and it works well in our application, although we are using an oauth-like system not google sign in.

[TMSCH]

@CicholGricenchos how are you using meta refresh in a client OAuth like setup?

@razor-1 it's a good idea we'll investigate.

[onyxblade]

@TMSCH
We have two websites: S a central site and A a sub site. The first time when a user visits A, it needs to follow an A(entered url) -> S(generate_auth_code) -> A(consume_auth_code) -> A(entered url) redirection to get a session token from S's cookies. If we use 307 for redirections(for each ->), the A -> S cannot access to S's cookies and S -> A cannot access to A's cookies either.

Then we use meta refresh to replace the 307 redirections. The server returns a 200 and a html with a meta refresh tag containing a redirection url, which takes effect in 0.00001 second. This works just fine.

There are still differences between our case and another's. For example, our website didn't return 200 in the first place, which may trigger the 24 hrs rule of ITP since it may not consider 307 a user interaction. So it's still important to find out which step caused the problem in this thread exactly.

[max-mykhailenko]

with cookiepolicy: 'none', all works

auth2 = window.gapi.auth2.init({
    client_id: 'xxx',
    cookiepolicy: 'none',
  });

I don't know what exactly doing this, but it works

[emanuel1025]

@TMSCH Hi. We can see this same issue at Qalaxia.

I am using Safari 11.0.2 on MacOS High Sierra 10.13.2.

This can be replicated by enabling Safari's "Prevent cross-site tracking" feature and accessing the website 24 hours after the user has logged out. Attempting to login after using attachClickHandler() or signIn() opens up an empty pop-up window which immediately closes. The success and failure callbacks are never called.

If Google Auth is only used in your context to authenticate users (and you're not using it to authorize users) you could use cookies on your own domain to track the user's session state.

What does this mean? In my case, the user is not logged in at all.

[khaight]

Is anyone still having this issue in Safari when "Prevent cross-site tracking" is enabled? When I isSignedIn.get() it always returns false.

    fetchBasicProfile: true,
    scope: 'profile',
    ux_mode: 'redirect',
    prompt: 'select_account',
    cookiepolicy: 'none'