Reauthenticate the user before launching Smart Lock setup app.

chrome/browser/chromeos/login/easy_unlock/short_lived_user_context.cc

+// Copyright 2014 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/chromeos/login/easy_unlock/short_lived_user_context.h"
+
+#include "base/bind.h"
+#include "base/location.h"
+#include "base/task_runner.h"
+#include "chromeos/login/auth/user_context.h"
+
+namespace chromeos {
+
+namespace {
+
+// The number of minutes that the user context will be stored.
+const int64 kUserContextTimeToLiveMin = 10;

[tbarzic, 2014/10/27 21:44:43]

Do you mean Max?

[Tim Song, 2014/10/31 17:57:37]

This should say kUserContextTimeToLiveMinutes.

+
+}  // namespace
+
+ShortLivedUserContext::ShortLivedUserContext(const UserContext& user_context,
+                                             base::TaskRunner* task_runner)
+    : user_context_(new UserContext(user_context)), weak_ptr_factory_(this) {
+  task_runner->PostDelayedTask(
+      FROM_HERE,
+      base::Bind(&ShortLivedUserContext::DeleteUserContext,
+                 weak_ptr_factory_.GetWeakPtr()),
+      base::TimeDelta::FromMinutes(kUserContextTimeToLiveMin));

[tbarzic, 2014/10/27 21:44:43]

What if the setup exceeds 10 min? Does setup fail in any way; or do we just
fallback to current behaviour?

Is there a way to avoid the magic constant here (maybe bind the lifetime to
setup app being active)?

Maybe it would make more sense to ask for credentials right before we need it
(i.e. before saving list of remote devices)?

[Tim Song, 2014/10/31 17:57:37]

The UI decision was to show the reauth before the app is launched, so we have to
cache the user context. Additionally, we will need to cache the user context
briefly. when checking for the lure notification. I think the fallback is okay,
since it's pretty rare for someone to spend 10 minutes on this setup. We want to
avoid keeping the credentials around if the user keeps this window open
indefinitely.

I added logic binding the lifetime of the user context to the lifetime of the
app window.

[tbarzic, 2014/10/31 18:24:08]

Yeah, I was thinking that we may show an error message in the setup UI (and
clear the user context when that happens; I agree that we should not keep the
credentials indefinitely) rather than just continue setup and commit the keys on
next authentication. Though, I guess this is good enough for now.

Maybe we could also add some metrics for the time the credentials are kept
around in order to see how long "short-lived" should be (10 min is not that
short :) )

[Tim Song, 2014/11/01 03:16:52]

I can add a check in the app to close the window in 10 minutes. If I recall, we
actually had this logic a while back when the setup was encrypted, so we can
timeout the temporary key.

+}
+
+ShortLivedUserContext::~ShortLivedUserContext() {
+}
+
+void ShortLivedUserContext::DeleteUserContext() {
+  if (user_context_.get()) {
+    user_context_->ClearSecrets();
+    user_context_.reset();
+  }
+}
+
+}  // namespace chromeos