search

webcompat / web-bugs

A place to report bugs on websites.
https://webcompat.com
Mozilla Public License 2.0
747 stars 67 forks source link

accounts.google.com - Unable to sign in via Google #32144

Closed singhnp closed 5 years ago

singhnp commented 5 years ago

URL: https://accounts.google.com/o/oauth2/auth?redirect_uri=storagerelay://https/www.fandango.com?id=auth575152

Browser / Version: Firefox Mobile 68.0 Operating System: Android Tested Another Browser: No

Problem type: Something else Description: oauth did not work Steps to Reproduce: I logged into my Google account for oauth on Fandango, and after I logged in, nothing appeared.

Browser Configuration
  • None

From webcompat.com with ❤️

cipriansv commented 5 years ago

Thank you for your report @singhnp. I am not sure what your reported issue is about. Could you provide some accurate steps to reproduce it so that we can investigate what might lead to this behavior?

singhnp commented 5 years ago

Sure!

  1. Go to: https://www.fandango.com/account/signin

  2. Click "Sign in with Google"

  3. Log into Google (browser skips this step if cookies are present and you're already logged into Google)

  4. Browser tab navigates to blank page with the following url: https://accounts.google.com/o/oauth2/auth?redirect_uri=storagerelay%3A%2F%2Fhttps%2Fwww.fandango.com%3Fid%3Dauth690477&response_type=permission%20id_token&scope=email%20profile%20openid&openid.realm=&client_id=863718328551-46ca5t4fmgso72fmmpltqhei67dnvuqr.apps.googleusercontent.com&ss_domain=https%3A%2F%2Fwww.fandango.com&fetch_basic_profile=true&gsiwebsdk=2

softvision-sergiulogigan commented 5 years ago

Thanks @singhnp for the explicit STR! This really helps.

After I login with Google, I am being redirected here: image

Allowing the access, I am being redirected to a blank page. image

Let's try Chrome.

image

Cool! Let's move this to Needsdiagnosis.

Tested with: Browser / Version: Firefox Nightly 68.0a1 (2019-06-05), Firefox Focus 9.0, Firefox Fenix (Preview) 1.0.1923 Operating System: Windows 10 Pro, OnePlus 6 (Android 9) - 1080 x 2280 pixels, 19:9 ratio (~402 ppi pixel density)

Also, the issue is not reproducible on Firefox Nightly.

adamopenweb commented 5 years ago

Thanks @softvision-sergiulogigan. Just want to clarify that this does reproduce with Firefox Focus? But not Firefox Nightly (fennec).

softvision-sergiulogigan commented 5 years ago

@adamopenweb This is happening only on Fenix (even with TP OFF) and Focus. Fennec and Chrome both open the page after signing in with Google.

wisniewskit commented 5 years ago

In Fennec, I see this logged:

XHR GET [https://accounts.google.com/o/oauth2/iframerpc](https://ssl.gstatic.com/accounts/o/1576614419-v2-idpiframe.js)?action=checkOrigin&origin=https%3A%2F%2Fwww.fandango.com&client_id=863718328551-46ca5t4fmgso72fmmpltqhei67dnvuqr.apps.googleusercontent.com
[HTTP/2.0 200 OK 71ms]

Use of Mutation Events is deprecated. Use MutationObserver instead. [ChangeMonitor-latest.js](https://cdnssl.clicktale.net/www/ChangeMonitor-latest.js):30:667

XHR POST https://ing-district.clicktale.net/ctn_v2/wr/?2315695001534823&124&10&1&1&0&105&subsid=119833&msgsize=20
[HTTP/1.1 200 OK 42ms]

XHR POST https://ing-district.clicktale.net/ctn_v2/wr/?2315695001534823&124&10&2&2&0&105&subsid=119833&msgsize=20
[HTTP/1.1 200 OK 41ms]

XHR POST https://ing-district.clicktale.net/ctn_v2/wr/?2315695001534823&124&10&3&0&1&8&subsid=119833&msgsize=20
[HTTP/1.1 200 OK 39ms]

XHR POST https://ing-district.clicktale.net/ctn_v2/wr/?2315695001534823&124&10&4&0&2&8&subsid=119833&msgsize=20
[HTTP/1.1 200 OK 114ms]

XHR POST https://siteintercept.qualtrics.com/WRSiteInterceptEngine/Targeting.php?Q_ZoneID=ZN_9Gnmr4G3ce3Ts9L&Q_CLIENTVERSION=1.5.0&Q_CLIENTTYPE=web
[HTTP/2.0 200 OK 125ms]

XHR GET https://accounts.google.com/o/oauth2/iframerpc?action=issueToken&response_type=token%20id_token&login_hint=AJDLj6JmPoJVmpN7ajIjiJm_H4lYsk19JbAjHVfOHxTK8a6f6-Df54f1K42VdtN7cFwCY3oslMxNOtmfGcUDmDWAGuromrkIbg&client_id=863718328551-46ca5t4fmgso72fmmpltqhei67dnvuqr.apps.googleusercontent.com&origin=https%3A%2F%2Fwww.fandango.com&scope=openid%20profile%20email&ss_domain=https%3A%2F%2Fwww.fandango.com
[HTTP/2.0 200 OK 201ms]

XHR PUT https://www.fandango.com/api/account/Connect?applicationType=GoogleSignIn&accessToken=eyJhbGciOiJSUzI1NiIsImtpZCI6IjY4NjQyODlmZmE1MWU0ZTE3ZjE0ZWRmYWFmNTEzMGRmNDBkODllN2QiLCJ0eXAiOiJKV1QifQ.eyJpc3MiOiJhY2NvdW50cy5nb29nbGUuY29tIiwiYXpwIjoiODYzNzE4MzI4NTUxLTQ2Y2E1dDRmbWdzbzcyZm1tcGx0cWhlaTY3ZG52dXFyLmFwcHMuZ29vZ2xldXNlcmNvbnRlbnQuY29tIiwiYXVkIjoiODYzNzE4MzI4NTUxLTQ2Y2E1dDRmbWdzbzcyZm1tcGx0cWhlaTY3ZG52dXFyLmFwcHMuZ29vZ2xldXNlcmNvbnRlbnQuY29tIiwic3ViIjoiMTE2MTQwMTQ2NzQ1NDc5MTQ0NzgwIiwiZW1haWwiOiJ3ZWJjb21wYXQudGVzdGVyQGdtYWlsLmNvbSIsImVtYWlsX3ZlcmlmaWVkIjp0cnVlLCJhdF9oYXNoIjoieWp4MWtiY2JNWnB2ZloxdUFRVk1QQSIsIm5hbWUiOiJXZWJDb21wYXQgVGVzdGVyIiwicGljdHVyZSI6Imh0dHBzOi8vbGg2Lmdvb2dsZXVzZXJjb250ZW50LmNvbS8tLXZCMU9BU3BObUkvQUFBQUFBQUFBQUkvQUFBQUFBQUFBQUEvQUNIaTNyZi1zc1VJQzdZTjlkaUVkMHFvN1JpQUh5QTVPZy9zOTYtYy9waG90by5qcGciLCJnaXZlbl9uYW1lIjoiV2ViQ29tcGF0IiwiZmFtaWx5X25hbWUiOiJUZXN0ZXIiLCJsb2NhbGUiOiJlbiIsImlhdCI6MTU2MTQwOTI1NywiZXhwIjoxNTYxNDEyODU3LCJqdGkiOiIxMzgyOTJiMjMzY2E0NWQ2MDQ4YTAxOTQzZjc2M2VmOGJhNWExNzVhIn0.chUftCD4NR7zKLWw7nv_J672jLKRHFyY01DlBf6ziU9t1ko6q1zj8qSinGSDNNMXXCC4yVCQVGAFR0XZ_s2q8-wUFyFfK0lr2fnHZ4mLqgFnfXqsC6veVnSwPRHyd1umwwUIAxLOBIpOtfkZKrbW5OifdNmro2E20dY2-X98QKdrrhqw2po2_z-SAiKEuoGrjAHEyVqz7gxd5M2QsDg1j3Nh2LxljTxtCZo5V4iomLjbCvjN3cNoQ10tKMwzXKoSDsGb4pK_uNZbxG5oOL8SREPizrmduxATAnrC0r64RuIc6ItIbtFoObhYOwo3m2fCisYqD8Pl3X2xXmQHhr-hvg

Navigated to https://www.fandango.com/?login=success&accounttype=google

But on the Reference Browser I see this instead:

XHR GET https://accounts.google.com/o/oauth2/iframerpc?action=checkOrigin&origin=https%3A%2F%2Fwww.fandango.com&client_id=863718328551-46ca5t4fmgso72fmmpltqhei67dnvuqr.apps.googleusercontent.com
[HTTP/2.0 200 OK 183ms]

XHR POST https://siteintercept.qualtrics.com/WRSiteInterceptEngine/Targeting.php?Q_ZoneID=ZN_9Gnmr4G3ce3Ts9L&Q_CLIENTVERSION=1.5.0&Q_CLIENTTYPE=web
[HTTP/2.0 200 OK 195ms]

XHR POST https://ing-district.clicktale.net/ctn_v2/wr/?2315692468142283&124&10&1&1&0&105&subsid=119833&msgsize=20
[HTTP/1.1 200 OK 43ms]

Use of Mutation Events is deprecated. Use MutationObserver instead. ChangeMonitor-latest.js:30:667

Navigated to https://accounts.google.com/o/oauth2/auth?redirect_uri=storagerelay%3A%2F%2Fhttps%2Fwww.fandango.com%3Fid%3Dauth502024&response_type=permission%20id_token&scope=email%20profile%20openid&openid.realm=&client_id=863718328551-46ca5t4fmgso72fmmpltqhei67dnvuqr.apps.googleusercontent.com&ss_domain=https%3A%2F%2Fwww.fandango.com&fetch_basic_profile=true&gsiwebsdk=2

Google Login Failed: popup_blocked_by_browser [googlePlus.js](https://images.fandango.com/r1.0.695/redesign/areas/registration/js/googlePlus.js):42:11

XHR POST https://accounts.google.com/_/signin/v1/lookup [HTTP/2.0 200 OK 133ms]

Navigated to https://accounts.google.com/o/oauth2/auth?redirect_uri=storagerelay%3A%2F%2Fhttps%2Fwww.fandango.com%3Fid%3Dauth502024&response_type=permission+id_token&scope=email+profile+openid&openid.realm&client_id=863718328551-46ca5t4fmgso72fmmpltqhei67dnvuqr.apps.googleusercontent.com&ss_domain=https%3A%2F%2Fwww.fandango.com&fetch_basic_profile=true&gsiwebsdk=2&from_login=1&as=oBDT5Uz6jsXrbDquwRWppA&authuser=0

Scripts may not close windows that were not opened by script. auth:1:30

So it appears that for some reason, Google's oauth2 framework is not actually doing the issueToken step on GeckoView, but is instead navigating its iframe away to some storage relay service with a redirect, which fails due to being blocked by the browser (popup_blocked_by_browser).

It's hitting this onFailure, and the corresponding onSuccess it should be hitting makes me think that yes, something is being "blocked" by GeckoView, causing this issue:

    onSuccess: function(googleUser) {
        var token = googleUser.getAuthResponse().id_token;

        Fandango.socialHelper.connect('GoogleSignIn', token, function(isSuccess, response) {
            Fandango.socialHelper.accountTracking(isSuccess, response, 'google');
        });
    },
    onFailure: function(authResult) {
        console.log('Google Login Failed: ' + authResult['error']);
    },

But that doesn't really explain why only Fenix is taking that code-path in the first place, with Fennec never hitting the googlePlus.js script at all.

Both browsers do the same initial XHR to oauth2 for checkOrigin, and get the same JSON response:

{"valid":true}

But only Fennec proceeds to do the issueToken XHR, in this stack trace:

ee               [https://ssl.gstatic.com/accounts/o/1576614419-v2-idpiframe.js](https://ssl.gstatic.com/accounts/o/1576614419-v2-idpiframe.js):128:94
ie               https://ssl.gstatic.com/accounts/o/1576614419-v2-idpiframe.js:128:388
m.uc             https://ssl.gstatic.com/accounts/o/1576614419-v2-idpiframe.js:158:84
Y/<              https://ssl.gstatic.com/accounts/o/1576614419-v2-idpiframe.js:166:129
xe.prototype.Pc  https://ssl.gstatic.com/accounts/o/1576614419-v2-idpiframe.js:144:225
b                https://ssl.gstatic.com/accounts/o/1576614419-v2-idpiframe.js:155:51

GeckoView instead gets redirected to the strange storagerelay:// URL. That parameter seems to be added here in this script:

    SF = function(a, c, f, g) {
        if (!a.$k) throw Error("ob");
        a.X4 = f || a.Hda || "auth" + Math.floor(1E6 * Math.random() + 1);
        c = c || {};
        c.extraQueryParams = c.extraQueryParams || {};
        if (!c.extraQueryParams.redirect_uri) {
            var h = a.Db.split("//");
            f = c.extraQueryParams;
            var l = h[0],
                n = l.indexOf(":");
            0 < n && (l = l.substring(0, n));
            h = ["storagerelay://", l, "/", h[1], "?"];
            h.push("id=" + a.X4);
            f.redirect_uri = h.join("")
        }
        return Q1(a.Rd, a.Ix, a.$k, a.bY, !0, c, g)
    };

That is, the parameter appears to be is a stand-in value the oauth2 API provides when the consumer (in this Fandango) does not provide one themselves.

But again, that doesn't explain why Fennec isn't hitting this same problem. Something different must be happening between the successful checkOrigin RPC, and the next step, which causes Google's script to attempt the faulty redirect on GeckoView.

Unfortunately I can't figure that much more out from their minified code given the stack traces I have to work with, and a non-functioning remote debugger panel (it just stays blank for me on today's nightly).

@DenSchub, does the debugger remote devtools panel work for you right now with a Fenix build? If so, maybe you could set a breakpoint on that SF function above, and see why Fenix is hitting that servicerelay:// code in the first place, compared to Fennec?

denschub commented 5 years ago

So, interesting side note: geckoview_example actually crashes when trying to reproduce this, but that might be completely unrelated.

After spending way too much time following Tom's great work, trying to figure out why GeckoView ends up on a different code path than Fenix does, but eventually gave up. I then proceeded to analyse where that issueToken request in Fennec is getting spawned, in the hopes to find the cause of the issue somewhere around that stack. And at this point, I realized diagnosing so short after All Hands requires more coffee.

That request does not happen within the authentication page, but on the site that has the login button placed on it. And there is a significant difference between the two browsers. For some reason, in Fennec, the Login window opens in a new tab - which it does not do in GeckoView. The issueToken request is triggered by a function that effectively gets called by a window.addEventListener("message"). And the message it is looking for gets sent inside the Sign In with Google window, and it's really just sending a bunch of auth info with it. When the message is sent, the authentication window calls window.close().

In GeckoView, there is no new tab/window, but instead, the browser just navigates away. This makes the message useless, as there is no opener to send it to, and it also results in the window.close() being rejected. And there even is a hint for that, as the console says

Scripts may not close windows that were not opened by script

So question here is "why is opening the authentication window failing", and not "why is the login failing" - because the login is probably working just fine. Maybe that's what @wisniewskit said, but it's not actually an iFrame for me, just a regular old page load, so I got confused.

Google is doing nothing special here at all, just a

window.open(
  "https://accounts.google.com/o/oauth2/auth...",
  "authPopup379295",
  "toolbar=no,location=yes,directories=no,status=no,menubar=no,scrollbars=yes,resizable=yes,copyhistory=no,width=380,height=600,top=20,left=10"
);

which should work just fine. They even have source checking if a window was opened, to trigger the popup blocker warning, etc.

And sure enough, a quick test of simply running window.open("https://mozilla.org", Math.random().toString()) in Fenenc shows a popup warning, and after accepting it, it opens a new window. On the reference browser and Fenix, however, it shows a popup warning, and on confirming, it proceeds to load the URL in the same tab. Not good. It seems we already discovered this for the Reference Browser and filed bug 1557510 for it, but I did not see this being tracked for Fenix. So I filed a bug at https://github.com/mozilla-mobile/fenix/issues/3702.

This is an issue that has to be addressed within Fenix, there is nothing at all the site can do about this. Therefore, let's close this as a duplicate of https://github.com/mozilla-mobile/fenix/issues/3702 and hope that's fixed soon.

lock[bot] commented 5 years ago

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue at https://webcompat.com/issues/new if you are experiencing a similar problem.