Cancel client auth requests when not promptable.

chrome/browser/extensions/xhr_apitest.cc

Index: chrome/browser/extensions/xhr_apitest.cc
diff --git a/chrome/browser/extensions/xhr_apitest.cc b/chrome/browser/extensions/xhr_apitest.cc
new file mode 100644
index 0000000000000000000000000000000000000000..40c3b292efc4cf799ea372a5775b8afd898b9740
--- /dev/null
+++ b/chrome/browser/extensions/xhr_apitest.cc
@@ -0,0 +1,29 @@
+// Copyright 2015 The Chromium Authors. All rights reserved.
+// Use of this source code is governed by a BSD-style license that can be
+// found in the LICENSE file.
+
+#include "chrome/browser/extensions/extension_apitest.h"
+#include "net/test/spawned_test_server/spawned_test_server.h"
+
+// Test that fetching a URL using TLS client auth doesn't crash, hang, or
+// prompt.
+IN_PROC_BROWSER_TEST_F(ExtensionApiTest, XhrTlsClientAuth) {
+  // Launch HTTPS server.
+  net::SpawnedTestServer::SSLOptions ssl_options;
+  ssl_options.request_client_certificate = true;
+  net::SpawnedTestServer https_server(
+      net::SpawnedTestServer::TYPE_HTTPS, ssl_options,
+      base::FilePath(FILE_PATH_LITERAL("content/test/data")));
+  ASSERT_TRUE(https_server.Start());
+
+  std::string url = https_server.GetURL("").spec();
+  ASSERT_TRUE(RunExtensionTestWithArg("xhr", url.c_str())) << message_;

[davidben, 2015/02/06 22:39:38]

It's a bit of a nuisance that this test (and the one below) doesn't actually
assert that the extension actually hit the server. Any ideas on how best to
intercept the net stack here while still forwarding to the real request? I just
verified that commenting out the fix still crashed.

[mmenke, 2015/02/10 17:19:10]

Can we check if the displayed page has ERR_SSL_CLIENT_AUTH_CERT_NEEDED
displayed?  Not lovely, but a number of tests do that.

There may be some way to hook the URLRequest to get its final status, I'm not
sure, though (A ResourceThrottle?  Not sure they get the final status code
unless they do something in their destructor...Which is hideous.  Watching the
ErrorCodesForMainFrame3 histogram also seems really ugly).  A
WebContents::Observer?  They get network error codes, don't they?

[davidben, 2015/02/10 20:28:49]

It's an XHR made by the background page of an extension, so there's not much to
be displayed. :-) Also the extension itself doesn't get the error code because
of same-origin.
I don't think WCO exposes any useful hooks here. This isn't a navigation but a
network request from a top-level. I'm not sure there's a terribly easy way to
inject a ResourceThrottle either. It'd need to be something that you can attach
extra bits after initialization, rather than pass in a dependency like something
reasonable, since this a browser test and the normal browser assembly has
already started.

[mmenke, 2015/02/10 20:39:20]

Oh...Erm...right, was forgetting this wasn't a navigation.
The CrossSite tests inject ResourceThrottles by using an RDHDelegate.  That same
hook can also be used to hook up anything else you want to a URLRequest
(UserData that does something during destruction?  You could just check that the
URLRequest is created for the right URL and then destroyed by using a UserData
object, for instance).  Anyhow, not sure it's worth it.

[davidben, 2015/02/10 22:20:52]

Mmm. I'm a little worried about these tests swapping out random delegates at the
level of RDHDelegate and stuff. I don't know anything about extensions and
they'll probably get upset if, say, their code in ChromeNetworkDelegate got
pulled out.

+}
+
+// Test that fetching a URL using HTTP auth doesn't crash, hang, or prompt.
+IN_PROC_BROWSER_TEST_F(ExtensionApiTest, XhrHttpAuth) {
+  ASSERT_TRUE(StartSpawnedTestServer());
+
+  std::string url = test_server()->GetURL("/auth-basic").spec();
+  ASSERT_TRUE(RunExtensionTestWithArg("xhr", url.c_str())) << message_;
+}