New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 850961 link

Starred by 1 user

Issue metadata

Status: Fixed
Owner:
Closed: Jun 2018
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux , Windows , Mac
Pri: 2
Type: Bug



Sign in to add a comment

[Dice] Account signed out after creation

Project Member Reported by droger@chromium.org, Jun 8 2018

Issue description

Steps:
0) Enable DICE
1) create a new chrome profile
2) In the first screen of the first run experience, click "Signin"
3) On Gaia signin page, click "Create account"
4) Go through the account creation flow (which included SMS verification, accepting terms of service and privacy policy, and another pop up which looked like narnia)

Expected:
Account is signed-in on the web.
Sync confirmation dialog should show up.

Actual:
Not signed in on the web, no token in Chrome.
No Sync confirmation dialog shown.
I believe I was signed-in on the web for a brief period of time, since my account was shown in the top right corner of the NTP (until I reloaded the ntp).


I suppose the reconcilor signed out the account. Maybe Gaia did not send a refresh token?

 
Components: Services>SignIn

Comment 2 by yananj@google.com, Jun 8 2018

The OAuth code is returned, in response to /_signup/getcredentialresp.
There is a redirect to /signin/chrome/sync/finish, that request is cancelled somehow and there is request to /_chrome/newtab that opens a NTP immediately.

Attached the HAR file on a M3 browser, I can reproduce on M2 also.
m3_chromesync_signup
2.0 MB View Download

Comment 3 by ew...@chromium.org, Jun 8 2018

Cc: tmartino@chromium.org
Labels: -Pri-3 Hotlist-DICE-Followup OS-Linux OS-Mac OS-Windows Pri-2
Uh-oh!

Yanan, when you say the request is cancelled somehow, is that a client issue or a server issue? Sounds like the client is ignoring the redirect to /signin/chrome/sync/finish?

Is this only an issue with the FRE, or with other access points as well? I imagine it might be an FRE-specific issue, since we do some redirects after the user finishes the FRE to the NTP. David, if you need help navigating the FRE code, +Tommy should be able to give you pointers.

Comment 4 by yananj@google.com, Jun 8 2018

I think it's a client issue :(

The server side is WAI
1. Disable Dice
2. Manually inject request header: x-chrome-id-consistency-request: client_id=77185425430.apps.googleusercontent.com,signin_mode=all_accounts,signout_mode=show_confirmation
3. Hit https://accounts.google.com/signin/chrome/sync?continue=https://www.google.com
4. Go through create account flow
5. x-chrome-id-consistency-response: action=SIGNIN* response header sent in /_signup/getcredentials
6. x-chrome-id-consistency-response: action=ENABLE_SYNC* response header sent in /signin/chrome/sync/finish

So if request to /signin/chrome/sync/finish is sent to server, it would have returned the response. It seems request to /_chrome/newtab interferes with the previous one and cancelled it

I'm checking regular flow.

Comment 5 by yananj@google.com, Jun 8 2018

Doh, I spoke too soon. Apparently step 5 sets the header with an empty authorization_code. It's a server bug. I'm tracking it in b/109941619

Comment 6 by ew...@chromium.org, Jun 8 2018

Status: ExternalDependency (was: Assigned)
Phew! OK, I'm going to mark this as ExternalDependency. We can mark it as Fixed once the internal bug is fixed. Thanks for the quick investigation Yanan!

Comment 7 by droger@chromium.org, Jun 20 2018

As per the internal bug, this should be fixed now, right?

Comment 8 by yananj@google.com, Jun 20 2018

Yes!

Comment 9 by ew...@chromium.org, Jun 20 2018

Status: Fixed (was: ExternalDependency)

Sign in to add a comment