Setup Sync to use OAuth token for managed users.

chrome/browser/sync/profile_sync_service.cc

Index: chrome/browser/sync/profile_sync_service.cc
diff --git a/chrome/browser/sync/profile_sync_service.cc b/chrome/browser/sync/profile_sync_service.cc
index bbc69cf44c34338feb2eb2fd713f4db38b426dd3..17c3c551ef714a17f9a047f87842037f9c43f512 100644
--- a/chrome/browser/sync/profile_sync_service.cc
+++ b/chrome/browser/sync/profile_sync_service.cc
@@ -120,6 +120,9 @@ static const char* kOAuth2Scopes[] = {
   GaiaConstants::kGoogleTalkOAuth2Scope
 };
 
+static const char* kManagedOAuth2Scopes[] = {
+  GaiaConstants::kChromeSyncManagedOAuth2Scope
+};
 
 static const char* kSyncUnrecoverableErrorHistogram =
     "Sync.UnrecoverableErrors";
@@ -1923,8 +1926,14 @@ void ProfileSyncService::RequestAccessToken() {
     return;
   request_access_token_retry_timer_.Stop();
   OAuth2TokenService::ScopeSet oauth2_scopes;
-  for (size_t i = 0; i < arraysize(kOAuth2Scopes); i++)
-    oauth2_scopes.insert(kOAuth2Scopes[i]);
+  if (ManagedUserService::ProfileIsManaged(profile_)) {
+    for (size_t i = 0; i < arraysize(kManagedOAuth2Scopes); i++)
+      oauth2_scopes.insert(kManagedOAuth2Scopes[i]);
+  } else {
+    for (size_t i = 0; i < arraysize(kOAuth2Scopes); i++)
+      oauth2_scopes.insert(kOAuth2Scopes[i]);
+  }
+

[pavely, 2013/06/17 22:36:31]

Currently access token is passed to both sync server and xmpp server. I suspect
chromesync_playpen scope will not work with xmpp server and it will return
CREDENTIALS_REJECTED status which will cause ProfileSyncService to request
access token again. I didn't try it yet.
Could you try this scenario before committing.

If it is true then there should also be a change in
SyncManagerImpl::OnInvalidatorStateChange not to propagate CREDENTIALS_REJECTED
when running under managed user. 
Alternatively there could be change to disable notifications for MU completely
through InvalidatorFactory, but i don't have specific ideas on how to do it as
I'm not yet familiar with that code.

[Bernhard Bauer, 2013/06/18 13:44:35]

Hm, true. I did notice this when testing and worked around this by running
against the Python server (which accepts any token), but obviously that won't
work for production.
Me neither, but that doesn't stop me ;-)

I went with the latter approach, as it seems more dependency-inject-y to me to
not create the invalidator in the first place then to find out whether the
profile is managed deep in the bowels of the SyncManagerImpl or
ServerConnectionManager (both of which can't depend on Profile, AFAICT). So,
PTAL?

   OAuth2TokenService* token_service =
       ProfileOAuth2TokenServiceFactory::GetForProfile(profile_);
   // Invalidate previous token, otherwise token service will return the same