Refactor SecurityStateModel/Clients for simplicity and reusability.

components/security_state/content/web_contents_security_state_model_client.h

Index: components/security_state/content/web_contents_security_state_model_client.h
diff --git a/components/security_state/content/web_contents_security_state_model_client.h b/components/security_state/content/web_contents_security_state_model_client.h
new file mode 100644
index 0000000000000000000000000000000000000000..6b05b784cc56c9901e6a52069a49610615bf2f3b
--- /dev/null
+++ b/components/security_state/content/web_contents_security_state_model_client.h
@@ -0,0 +1,62 @@
+// 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.
+
+#ifndef COMPONENTS_SECURITY_STATE_CONTENT_WEB_CONTENTS_SECURITY_STATE_MODEL_CLIENT_H_
+#define COMPONENTS_SECURITY_STATE_CONTENT_WEB_CONTENTS_SECURITY_STATE_MODEL_CLIENT_H_
+
+#include <memory>
+
+#include "base/macros.h"
+#include "components/security_state/core/security_state_model.h"
+#include "components/security_state/core/security_state_model_client.h"
+#include "third_party/WebKit/public/platform/WebSecurityStyle.h"
+
+namespace content {
+class NavigationEntry;
+struct SecurityStyleExplanations;
+class WebContents;
+}
+
+namespace security_state {
+
+// Uses a WebContents to provide a SecurityStateModel with the
+// information that it needs to determine the page's security status.
+class WebContentsSecurityStateModelClient : public SecurityStateModelClient {

[blundell, 2016/10/25 16:24:01]

drive-by nit: The Client naming signifies an interface that is implemented by
the embedder, so we shouldn't put a partial implementation of a Client interface
within a component itself. I suggest just making this class a helper class that
can be shared between the Chrome client and the new Headless client.

[Eric Seckler, 2016/10/25 16:43:58]

security_state/content/ basically is the content implementation of the
component, though (as compared to the iOS one). Thus, I'd argue that
implementing the components' client interface should be OK? It sounds like it
should from
https://www.chromium.org/developers/design-documents/layered-components-design .
But since this is my first exposure to components, I might be wrong :)

+ public:
+  explicit WebContentsSecurityStateModelClient(
+      content::WebContents* web_contents);
+  ~WebContentsSecurityStateModelClient() override;
+
+  void GetSecurityInfo(SecurityStateModel::SecurityInfo* result) const;
+
+  // Returns the SecurityStyle that should be applied to a WebContents
+  // with the given |security_info|. Populates
+  // |security_style_explanations| to explain why the returned
+  // SecurityStyle was chosen.
+  static blink::WebSecurityStyle GetSecurityStyle(
+      const SecurityStateModel::SecurityInfo& security_info,
+      content::SecurityStyleExplanations* security_style_explanations);
+
+  // SecurityStateModelClient:
+  void GetVisibleSecurityState(
+      SecurityStateModel::VisibleSecurityState* state) override;
+  bool UsedPolicyInstalledCertificate() override;
+  bool IsOriginSecure(const GURL& url) override;
+
+ protected:
+  virtual void CheckMalwareStatus(
+      content::NavigationEntry* entry,
+      content::WebContents* web_contents,
+      SecurityStateModel::VisibleSecurityState* state) = 0;
+
+ private:
+  content::WebContents* web_contents_;
+  std::unique_ptr<SecurityStateModel> security_state_model_;
+
+  DISALLOW_COPY_AND_ASSIGN(WebContentsSecurityStateModelClient);
+};
+
+}  // namespace security_state
+
+#endif  // COMPONENTS_SECURITY_STATE_CONTENT_WEB_CONTENTS_SECURITY_STATE_MODEL_CLIENT_H_