propagate proxy auth info into the browser context.

chrome/browser/chromeos/login/existing_user_controller.cc

Index: chrome/browser/chromeos/login/existing_user_controller.cc
diff --git a/chrome/browser/chromeos/login/existing_user_controller.cc b/chrome/browser/chromeos/login/existing_user_controller.cc
index 2df4994d51233e4fc5692c30d346ff2e5e5f7f3a..a255cf15b96e8ae944621e4cc5502e1aff30759e 100644
--- a/chrome/browser/chromeos/login/existing_user_controller.cc
+++ b/chrome/browser/chromeos/login/existing_user_controller.cc
@@ -73,6 +73,7 @@
 #include "content/public/browser/browser_thread.h"
 #include "content/public/browser/notification_service.h"
 #include "content/public/browser/notification_types.h"
+#include "content/public/browser/storage_partition.h"
 #include "content/public/browser/user_metrics.h"
 #include "google_apis/gaia/gaia_auth_util.h"
 #include "google_apis/gaia/google_service_auth_error.h"
@@ -128,6 +129,20 @@ void TransferContextAuthenticationsOnIOThread(
       default_profile_context_getter->GetURLRequestContext()->
       http_transaction_factory()->GetSession()->http_auth_cache();
   new_cache->UpdateAllFrom(*old_cache);
+
+  // Copy the auth cache from webview's context since the proxy authentication
+  // information is saved in webview's context.
+  content::StoragePartition* signin_partition = login::GetSigninPartition();

[nharper, 2017/01/19 00:42:17]

Is there a reason for doing this here instead of replacing the
ProfileHelper::GetSigninProfile() call at
TransferContextAuthenticationsOnIOThread's callsite with this? I don't know what
the implications of that would be.

[xiaoyinh(OOO Sep 11-29), 2017/01/19 01:32:08]

Thanks for the review. I just tried the normal login flow(without proxy), and it
didn't go through this function. I'm not sure though if
TransferContextAuthenticationsOnIOThread is only used to transfer proxy auth
data. If that's the case, we probably don't need
ProfileHelper::GetSigninProfile() anymore. Initially, I just don't want  to
break existing auth flow(if any) that are propagated though
ProfileHelper::GetSigninProfile().

xiyuan@, alemate@ might know better the history and usage of GetSigninProfile()
vs GetSigninPartition();

[xiyuan, 2017/01/19 17:20:26]

The Gaia is now served in webview and GetSigninPartition() should handle that.
However, there is still a couple of things use the signin profile directly: the
iframe in ToS page and captive portal window on the login screen. It is probably
safer to copy both.

However, it is a good point to call GetSigninPartition() on the callsite of
TransferContextAuthenticationsOnIOThread.
TransferContextAuthenticationsOnIOThread as the name indicates runs on the IO
thread. And GetSigninPartition() is not thread-safe and probably does not expect
to be called on IO thread. Can we change that?

+  if (signin_partition) {
+    net::URLRequestContextGetter* webview_context =
+        signin_partition->GetURLRequestContext();
+    net::HttpAuthCache* webview_cache = webview_context->GetURLRequestContext()
+                                            ->http_transaction_factory()
+                                            ->GetSession()
+                                            ->http_auth_cache();
+    new_cache->UpdateAllFrom(*webview_cache);
+  }
+
   VLOG(1) << "Main request context populated with authentication data.";
   // Last but not least tell the policy subsystem to refresh now as it might
   // have been stuck until now too.