Project: chromium Issues People Development process History Sign in
New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 15 users
Status: WontFix
Owner:
Closed: Jan 2017
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Mac
Pri: 2
Type: Bug



Sign in to add a comment
Cannot log in to Chrome using a Google Apps account with two-factor authentication: OnSyncConfigureRetry -- ProfileSyncService unusable: Configure failed to download.
Reported by isaac.he...@gmail.com, Dec 20 2011 Back to list
Chrome Version       : 17.0.963.12
OS Version: OS X 10.7.2
Other browsers tested: n/a

What steps will reproduce the problem?
1. Try to log into Chrome to (eg.) set up Chrome Sync. Use a Google Apps account with 2-factor authentication
2. Chrome prompts you for an application-specific password
3. Provide app-specific password from https://accounts.google.com/b/0/IssuedAuthSubTokens

What is the expected result?
4. Sync is set up and begins

What happens instead?
4. An error message "Account sign-in details are out of date" briefly flashes, and Chrome returns to its not-logged-in state

Screencast at http://screencast.com/t/7Cga7MvIh.

Related bug: the error message is displayed FAR too briefly. So much so that you HAVE to use a screencast capture utility to freeze-frame it and read it.

UserAgentString: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_7_2) AppleWebKit/535.11 (KHTML, like Gecko) Chrome/17.0.963.12 Safari/535.11


 
I have the same issue using version 16.0.912.63m
Comment 2 by jar@chromium.org, Dec 23 2011
Labels: -Area-Undefined Area-Internals Internals-Network-Auth
Labels: Action-FeedbackNeeded
Is this still happening in the latest Chrome build (stable is now 19.0.1084.46)?
Comment 4 by t...@camilleri.cc, Jun 1 2012
I'm running 20.0.1132.21 beta and I see the same issue with the same errors (Account sign-in details are out of date). I also see "Oops, Sync has stopped working".
Yup, still an issue in 21.0.1145.0 dev too.
Labels: -Internals-Network-Auth Feature-Sync
Tried the about:flags OAuth setting in v21dev and indeed, it asks me for my OTP (rather than ASP) as part of sign-in. Sign-in still fails, though, and takes me back to the login page with a message "Oops, Sync has stopped working" (http://the.twtt.rs/2e3x3Y3H0V3e0q1L220h).
Comment 8 by Deleted ...@, Jun 1 2012
When you get this error, can you go to about:sync in another tab and copy/paste the contents here? I'd like to see what issue Sync is reporting. Thanks!
Comment 9 by t...@camilleri.cc, Jun 1 2012
Summary
Summary	Unrecoverable error detected
Version Info
Client Version	 Mac OS X 20.0.1132.21 (139451) beta
Server URL	https://clients4.google.com/chrome-sync
Credentials
Client ID	none
Username	tim@camilleri.cc
Sync Token Available	true
Local State
Last Synced	Never
Sync First-Time Setup Complete	false
Initial Download Complete	false
Sync Backend Initialized	false
Syncing	false
Network
Throttled	false
Notifications Enabled	false
Encryption
Passphrase Required	false
Cryptographer Ready	false
Cryptographer Has Pending Keys	false
Encrypted Types	
Status from Last Completed Session
Sync Source	UNKNOWN
Download Updates	UNSET
Post Commit	UNSET
Process Commit Response	UNSET
Running Totals
Notifications Received	0
Cycles Without Updates	0
Cycles With Updates	0
Cycles Without Commits	0
Cycles With Commits	0
Cycles Without Commits or Updates	0
Cycles With Commit or Update	0
Updates Downloaded	0
Tombstone Updates	0
Reflected Updates	0
Conflict Resolved: Client Wins	0
Conflict Resolved: Server Wins	0
Transient Counters (this cycle)
Unsynced Count (before commit)	0
Encryption Conflicts	0
Hierarchy Conflicts	0
Simple Conflicts	0
Server Conflicts	0
Committed Items	0
Updates Remaining	0
Transient Counters (last cycle of last completed session)
Updates Downloaded	0
Committed Count	0
Entries	0
Routing Info
Unrecoverable error detected at /b/build/slave/chrome-official-mac/build/src/chrome/browser/sync/profile_sync_service.cc[395] OnSyncConfigureRetry : Configure failed to download.
Summary
Summary	Unrecoverable error detected
Version Info
Client Version	 Mac OS X 21.0.1155.2 (139341) dev
Server URL	https://clients4.google.com/chrome-sync/dev
Credentials
Client ID	none
Username	isaac@twitter.com
Sync Token Available	true
Local State
Last Synced	Never
Sync First-Time Setup Complete	false
Initial Download Complete	false
Sync Backend Initialized	false
Syncing	false
Network
Throttled	false
Notifications Enabled	false
Encryption
Passphrase Required	false
Cryptographer Ready	false
Cryptographer Has Pending Keys	false
Encrypted Types	
Status from Last Completed Session
Sync Source	UNKNOWN
Download Updates	UNSET
Post Commit	UNSET
Process Commit Response	UNSET
Running Totals
Notifications Received	0
Cycles Without Updates	0
Cycles With Updates	0
Cycles Without Commits	0
Cycles With Commits	0
Cycles Without Commits or Updates	0
Cycles With Commit or Update	0
Updates Downloaded	0
Tombstone Updates	0
Reflected Updates	0
Conflict Resolved: Client Wins	0
Conflict Resolved: Server Wins	0
Transient Counters (this cycle)
Encryption Conflicts	0
Hierarchy Conflicts	0
Simple Conflicts	0
Server Conflicts	0
Committed Items	0
Updates Remaining	0
Transient Counters (last cycle of last completed session)
Updates Downloaded	0
Committed Count	0
Entries	0
Routing Info
Unrecoverable error detected at /b/build/slave/chrome-official-mac/build/src/chrome/browser/sync/profile_sync_service.cc[397] OnSyncConfigureRetry : Configure failed to download.
Comment 11 by zea@chromium.org, Jun 1 2012
I'm not seeing any connections to our server in the past 8 days from either of the accounts you posted. Have you tried to connect recently? What happens if you try to access https://clients4.google.com/chrome-sync/time from your browser?
I accessed the URL. It downloaded a file called "time" containing 1338589269.
a GET for https://clients4.google.com/chrome-sync/dev 404's, though. I guess that's expected?
And yes, I've tried multiple times today to sync. The details above from about:sync were from half an hour or so ago.
isaac.hepworth@, https://clients4.google.com/chrome-sync/dev ought to 404; it is not a resource in and of itself, but is used as a base path to get to resources at the sub-paths /command and /time.

Is this a new profile? Are you syncing on another client?

Thanks.
It's not a new profile. I *am* syncing on another client (isaac.hepworth@gmail.com) and that works fine.

Just ran a trace using a local proxy. Seems like Chrome's POSTing to https://clients4.google.com/chrome-sync/dev/command/?client=Google+Chrome&client_id=my_id and getting back 401 Unauthorized.

Wondering now if there's a race condition, because the next three requests *after* that are to accounts.google.com to complete the OAuth login sequence and get a token.

Shouldn't it be authenticating me first, getting the token, and *then* POSTing to clients4.google.com?
These are in time order... http://the.twtt.rs/0V3F092X0H3v3D1V2a2P
Cc: rogerta@chromium.org
CCing roger since he knows the oauth flow best.
Cool, thanks. Roger—any thoughts?
The /o/oauth2/token requests are not part of the sign in process.  These must be requests made by other features within chrome, but I can't tell which ones.

The /o/oauth2/programmatic_auth request looks like its the exchange of the LSO token for an oauth2 token, and this is part of the sign in process.  However, the SigninTracker won't transition to the success state until the oauth2 token is available.

Drew: is it possible there is code that requests /chrome-sync/dev/command without using the SigninTracker to know when all is good to go?
Yes, probably (SigninTracker waits for the sync backend to start up, which
probably will hit chrome-sync URLs), but that should not happen until the
sync gaia token is loaded.
Comment 22 Deleted
Ah, interesting.  The token service loads all gaia tokens in parallel, including the sync and lso tokens.  Once it gets the lso token, it makes the /o/oauth2/programmatic_auth request to exchange it for an oauth2 token.

So I suppose its possible for the sync gaia token to be retrieved before the lso token and /o/oauth2/programmatic_auth request are made.  Which means the backend could make chrome-sync requests before the /o/oauth2/programmatic_auth request.  Yes/no?  If the answer is yes, is this bug?
Possibly? What is programmatic_auth used for (does sync have a dependency on a token other than the chromiumsync gaia token)?
Cc: munjal@chromium.org
programmatic_auth is used to exchange an lso auth token for an oauth2 oauthlogin-scoped token.  i'm not sure who uses this token though.  Maybe Munjal can say.
Login token is used to mint tokens for API calls that Chrome makes to Google on behalf of the user. For example, get profile picture of the user. It is also used to mint tokens for third parties (e.g. extensions and apps) to call Google APIs to access the user's data (with user's permission of course).

Also, login token can be used for everything (e.g. sync) and should be the only token we need to persist once we move everything to use that.
Okay, I now fully read the bug history. (Sorry for my earlier reply which was sent without reading the whole bug).

It is NOT a bug that we may end up making requests to sync servers *before* we make requests to /oauth2. The requests to sync servers only requires a token for "sync" service.

So when a user enter the password, the following happens:
1. In parallel, issue requests to /IssueToken to get tokens for "sync" and "lso" (and may be other services).
2. When the /IssueToken request for "sync" service is done, start up sync components (which will send requests to sync servers).
3. When the /IssueToken request for "lso" service is done, get OAuth2 login token (this corresponds to the /programmatic_oauth and two requests to /oauth2).

All that is by design.

Isaac, can you capture requests to /IssueToken (Which should be happening before requests to clients4.google.com) and send that to us?

I think what is happening here is that we are failing to get a token for "sync" service in this case.
I don't think it's a problem with not getting a sync token - the error we're seeing definitely happens after sync starts up, and sync will not start up until the token arrives.

So it seems more likely that we *are* minting a token, but for whatever reason we're getting an immediate error on our next request with that token?
You mean minting "sync" token or "oauth2" token?

If it reproes reliably, we should be able to figure out exactly what is happening if we have more logs and details of every HTTP request that happens in response to login.

Isaac, do you think you can provide us that? Specifically, can you grab all HTTP requests after you hit sign in and the response codes for them?
Yes, it repros reliably (like 100% of the time). I can grab the full set of HTTP requests for sure. If it includes token/auth information, though, would sharing this log compromise the security of my account?

Also, to make sure I set up my local proxy correctly—what domains should I make sure to include?

Issac: yes it may include tokens that you do not want to post to a bug report.

Instead of using a proxy, open a tab to "chrome://net-internals/" *before* you sign in, then press the "dump to file" button at the end of the process.  By default the "Strip private information" option is on, so this is safer to post to a bug report.
You should strip out the tokens. They do provide a lot of access to your account.

If you can configure it for google.com that is best. If not, then I think accounts.google.com and client4.google.com should cover it.
Cc: kochi@chromium.org pastarmovj@chromium.org
BTW, it looks like @pastarmovj is running into this on cros (we mint a token, but immediately get an auth error). It's possible that cros was getting a failure trying to refresh the tokens, though.

Julian, which acct were you using?
OK, here's my net-internals log. I set it recording, opened a new tab, and tried to sign in to sync using OAuth/OTP. After it fails to sign me in I'm left with this: http://the.twtt.rs/3q1O1m3y3w2r470t1P2F. (separate bug, that button shouldn't be disabled and say "Setting up..." like that, since it's failed).

Let me know if this gives you what you need. And thank you!

Isaac
net-internals-log.json
238 KB View Download
Summary: Cannot log in to Chrome using a Google Apps account with two-factor authentication: OnSyncConfigureRetry -- ProfileSyncService unusable: Configure failed to download. (was: NULL)
Adjusting title to reflect the error seen. FYI we are also seeing this for non 2-factor accounts, as in  issue 131091 .
 Issue 131091  has been merged into this issue.
Issue 114337 has been merged into this issue.
We received a repro from Chrome/iOS B19.0.1084.60.
Status: Untriaged
Work around: that works on my chrome 21.0.1171.0 dev-m windows 7

1) Login to any google services (gmail or blogger)
2) go to https://clients4.google.com/chrome-sync/command
3) you'll be asked for your password again. After entering your password, you will be redirected to your google account settings page(you can close that page)
4)now try chrome sync again from the menu and enter your google account user name and password.
5) Sync might work now.(it worked for me everytime)
I think this is some authentication problem (chrome sync has no intermediate screen(or not set up) to show the re enter password form) and the authentication fails and so the sync.


Owner: rogerta@chromium.org
Status: Assigned
Roger, are you the best person to look at this?
Comment 42 by w...@chromium.org, Aug 14 2012
I'm seeing this with Chromium Linux 23.0.1236.0 (151499)-devel (i.e. current tip-of-tree):
"Unrecoverable error detected at ../../chrome/browser/sync/profile_sync_service.cc[389] OnSyncConfigureRetry : Configure failed to download."
This is loading a profile logged in to my work account, with 2-factor enabled, for the first time in a month or so. It's likely that the auth token has expired / been revoked since I set the profile up.
Comment 43 by tim@chromium.org, Aug 14 2012
This is eerily reminiscent of  bug 122989  as well, except that there, the retry code path isn't hit yet we still failed to download the data (see comment 11). I'm really unsure how 2-factor could be related to this, but it's sure interesting.  The cases on 122989 are likely also 2-factor...
Comment 44 Deleted
 Issue 178337  has been merged into this issue.
Project Member Comment 46 by bugdroid1@chromium.org, Mar 9 2013
Labels: -Action-FeedbackNeeded Needs-Feedback
Project Member Comment 47 by bugdroid1@chromium.org, Mar 10 2013
Labels: -Area-Internals -Feature-Sync Cr-Services-Sync Cr-Internals
Labels: -Needs-Feedback
Status: WontFix
This is an obsolete bug since chrome no longer uses ASPs and no longer uses compartmentalized tokens.  Closing.
Comment 50 Deleted
Sign in to add a comment