User cloud policy token forwarder: Replace PO2TS::GetPrimaryAccountId() with SMB::GetAuthenticatedAc

chrome/browser/chromeos/login/login_utils.cc

Index: chrome/browser/chromeos/login/login_utils.cc
diff --git a/chrome/browser/chromeos/login/login_utils.cc b/chrome/browser/chromeos/login/login_utils.cc
index b9cbbe7b31f8520729036a055d122a0ec7eb2ab5..f61c00b473d743a9fed7a367c02cacdc1b57bf79 100644
--- a/chrome/browser/chromeos/login/login_utils.cc
+++ b/chrome/browser/chromeos/login/login_utils.cc
@@ -59,6 +59,8 @@
 #include "chrome/browser/profiles/profile.h"
 #include "chrome/browser/profiles/profile_manager.h"
 #include "chrome/browser/rlz/rlz.h"
+#include "chrome/browser/signin/signin_manager.h"
+#include "chrome/browser/signin/signin_manager_factory.h"
 #include "chrome/browser/sync/profile_sync_service.h"
 #include "chrome/browser/sync/profile_sync_service_factory.h"
 #include "chrome/browser/ui/app_list/start_page_service.h"
@@ -458,10 +460,9 @@ void LoginUtilsImpl::InitProfilePreferences(Profile* user_profile,
     // Make sure that the google service username is properly set (we do this
     // on every sign in, not just the first login, to deal with existing
     // profiles that might not have it set yet).
-    StringPrefMember google_services_username;
-    google_services_username.Init(prefs::kGoogleServicesUsername,
-                                  user_profile->GetPrefs());
-    google_services_username.SetValue(user_id);
+    SigninManagerBase* signin_manager =
+        SigninManagerFactory::GetForProfile(user_profile);
+    signin_manager->SetAuthenticatedUsername(user_id);

[xiyuan, 2014/03/01 16:45:28]

This makes SigninManagerBase be created earlier because InitProfilePreferences
is called in CREATE_STATUS_CREATED notification. Part of the profile is not
initialized (such as extension system). It appears to be working but want to see
if it rings bells for anyone.

Second, SigninManagerBase does not update kGoogleServicesUsername. It only
updates kGoogleServicesLastUsername. Would this be okay?

[Roger Tawa OOO till Jul 10th, 2014/03/01 18:30:05]

This line is not causing SM to be created earlier.  The change in the
UserCloudPolicyTokenForwarderFactory is doing that.  By the time execution gets
here, SM is already created and does not know the user_id.

That's a good catch for the second point.  Several options:

1/ set the pref and call SetAuthenticatedUsername() too.  I just quickly tested
that and it works for the test.
2/ Change SetAuthenticatedUsername() to set the pref iff its different.  I took
a look at all other places that call SetAuthenticatedUsername() and they are
doing so after noticing that the pref is set but SM is not.
3/ Move the setting of the pref from here to some place even earlier, before
UserCloudPolicyTokenForwarder or SM is created.

Option 1 makes the code here more consistent with the other code that calls
SetAuthenticatedUsername().  Option 2 might be safer though to prevent this from
happening in new code.  I don't think option 3 is great, just listed it for
completeness.

[xiyuan, 2014/03/01 18:40:36]

I like option 2 better because ideally we should let SM handle the pref and all
other places should not worry about that. 

   }
 }