Add API Key parsing for experimental APIs

content/browser/experiments/api_key.cc

Index: content/browser/experiments/api_key.cc
diff --git a/content/browser/experiments/api_key.cc b/content/browser/experiments/api_key.cc
new file mode 100644
index 0000000000000000000000000000000000000000..ce69791059e4b861e050991731fab7fdb2a31b15
--- /dev/null
+++ b/content/browser/experiments/api_key.cc
@@ -0,0 +1,67 @@
+// 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 "content/browser/experiments/api_key.h"
+
+#include <vector>
+
+#include "base/base64.h"
+#include "base/strings/string_number_conversions.h"
+#include "base/strings/string_split.h"
+#include "base/strings/string_util.h"
+#include "base/strings/utf_string_conversions.h"
+#include "base/time/time.h"
+
+namespace content {
+
+ApiKey::~ApiKey() {}
+
+scoped_ptr<ApiKey> ApiKey::Parse(const std::string& keyText) {
+  if (keyText.empty()) {
+    return nullptr;
+  }
+
+  // API Key should resemble:
+  // signature:origin:apiName:expiry
+  std::vector<std::string> parts =
+      SplitString(keyText, "|", base::KEEP_WHITESPACE, base::SPLIT_WANT_ALL);
+  if (parts.size() != 4) {
+    return nullptr;
+  }
+
+  const std::string& signature = parts[0];
+  const std::string& origin = parts[1];
+  const std::string& apiName = parts[2];
+  const std::string& expiry = parts[3];
+
+  uint64_t expiry_int;
+  if (!base::StringToUint64(expiry, &expiry_int)) {
+    return nullptr;
+  }
+
+  // signed data is (origin + "|" + api_name + "|" + expiry)
+  const std::string& data = keyText.substr(keyText.find('|') + 1);
+
+  return scoped_ptr<ApiKey>(
+      new ApiKey(signature, data, GURL(origin), apiName, expiry_int));

[chasej, 2015/12/15 19:43:41]

There is no validation of the origin or api name (i.e. for illegal use of the
delimiter character). I can understand that such validation is not strictly
necessary, as IsValidNow() only checks the date and signature (by design). 
However, that means Parse() can return a key, claiming it's valid, but it
contains bad values in the origin or api name.

I see two options:
1) The parsed API key only contains/exposes the signature, raw data, and expiry
date. It makes no claims/promises about the origin and api name.
2) Parsing adds validation of the origin and API name.

[iclelland, 2015/12/15 21:22:24]

Illegal use of the delimiter would result in more than four parts being present
in the `parts` variable.
I want parsing and validation to be separate concepts, so that we can construct
and work with syntactically correct, but invalid keys, when necessary. Parse()
can absolutely return an invalid key, and makes no claims as to its validity.
The only thing that should cause Parse() to return nullptr is if the key is
structurally *wrong*. A timestamp which isn't a number, for instance, or it has
the wrong number of parts. We could make a case that an insecure origin, or an
origin which isn't even a URL, means that we can't parse the key, but I'm less
convinced about validating the API name (unless it's just checking for
non-alphanumeric characters or similar)
1 is what we need right now. 2 will eventually be required, when we want to test
isExperimentEnabled from within the browser, as well as the renderer.

What if I do well-formedness testing on the key, as part of parse(), for now:
  - API name should be latin characters only (I don't think we can embed UTF8 or
control chars anywhere)
  - Origin should be a valid secure origin string.

Then the browser is just saying "this is a valid well-formed key", and the
renderer is responsible for determining whether the origin and api name are
appropriate for the current situation.

Would that work?

[chasej, 2015/12/16 15:41:17]

I agree with keeping parsing and validation separate.  So, Parse() can just
check that there are the correct number parts (4). The first three parts are
strings, which could be checked only for illegal characters.  The fourth part is
checked to ensure it is a number (the fact that it actually verifies it's
positive integer, that fits into a uint64 is an implementation detail).

[iclelland, 2015/12/16 17:04:37]

Cool -- if it's alright with you, I'll add the extra (character-set) validation
as a separate CL.

+}
+
+ApiKey::ApiKey(const std::string& signature,
+               const std::string& data,
+               const GURL& origin,
+               const std::string& api_name,
+               uint64_t expiry)
+    : signature_(signature),
+      data_(data),
+      origin_(origin),
+      api_name_(api_name),
+      expiry_(expiry) {}
+
+bool ApiKey::IsValidNow(const base::Time& now) const {
+  base::Time expiry_time =
+      base::Time::FromDoubleT((double)expiry_);
+  return expiry_time > now;
+}
+
+}  // namespace