Add support for multiple allowed domains

Add support for multiple allowed domains

Adds two new policies, RemoteAccessHostDomainList and
RemoteAccessHostClientDomainList, which allow specifying a list of
allowed domains. Deprecates the existing RemoteAccessHostDomain and RemoteAccessHostClientDomain policies.

BUG=624620
Review-Url: https://codereview.chromium.org/2682473003
Cr-Commit-Position: refs/heads/master@{#468149}
Committed: https://chromium.googlesource.com/chromium/src/+/10cd268f54d5f567b8834838ad0726e35dcdbe51

[rkjnsn, 2017-02-10 22:07:03]

rkjnsn@chromium.org changed reviewers:
+ jamiewalch@chromium.org

[rkjnsn, 2017-02-10 22:07:03]

As discussed, this needs some updates to the unit test scaffolding to implement
tests for cases other than RemoteAccessHostClientDomain with it2me, but the rest
of the code should be ready for a preliminary review.

[Sergey Ulanov, 2017-02-10 22:25:12]

sergeyu@chromium.org changed reviewers:
+ sergeyu@chromium.org

[Sergey Ulanov, 2017-02-10 22:25:13]

https://codereview.chromium.org/2682473003/diff/1/components/policy/resources...
File components/policy/resources/policy_templates.json (right):

https://codereview.chromium.org/2682473003/diff/1/components/policy/resources...
components/policy/resources/policy_templates.json:861: 'name':
'RemoteAccessHostDomainList',
Instead of adding new policy can we just extend RemoteAccessHostDomain to allow
comma-separate list of domains?

Same question about RemoteAccessHostClientDomainList

https://codereview.chromium.org/2682473003/diff/1/remoting/host/remoting_me2m...
File remoting/host/remoting_me2me_host.cc (right):

https://codereview.chromium.org/2682473003/diff/1/remoting/host/remoting_me2m...
remoting/host/remoting_me2me_host.cc:1073: void
HostProcess::HostDomainPolicyHelper(
Maybe call this VerifyHostDomain()?
In general most function names should be verbs, except events handlers (e.g.
OnClick()).

I think the logic in this file could be much simpler if we avoid adding a new
policy and instead allow comma-separated list for the policy we already have.

https://codereview.chromium.org/2682473003/diff/1/remoting/host/remoting_me2m...
remoting/host/remoting_me2me_host.cc:1139: for (const auto &value : *list) {
Space goes after '&, not before it, i.e. 'const auto& value'.

[rkjnsn, 2017-02-11 00:50:11]

https://codereview.chromium.org/2682473003/diff/1/components/policy/resources...
File components/policy/resources/policy_templates.json (right):

https://codereview.chromium.org/2682473003/diff/1/components/policy/resources...
components/policy/resources/policy_templates.json:861: 'name':
'RemoteAccessHostDomainList',
On 2017/02/10 22:25:13, Sergey Ulanov wrote:
> Instead of adding new policy can we just extend RemoteAccessHostDomain to
allow
> comma-separate list of domains?
> 
> Same question about RemoteAccessHostClientDomainList

Personally, I don't like the idea of parsing our own list from a string field
when policies support list fields. We could do it, but I don't like it.

[Sergey Ulanov, 2017-02-11 01:03:47]

sergeyu@chromium.org changed reviewers:
+ bartfab@chromium.org, pastarmovj@chromium.org

[Sergey Ulanov, 2017-02-11 01:03:48]

+bartfab, pastarmovj
Bartosz, Julian, is there a better way to upgrade an existing policy from string
to a list of strings?

https://codereview.chromium.org/2682473003/diff/1/components/policy/resources...
File components/policy/resources/policy_templates.json (right):

https://codereview.chromium.org/2682473003/diff/1/components/policy/resources...
components/policy/resources/policy_templates.json:861: 'name':
'RemoteAccessHostDomainList',
On 2017/02/11 00:50:11, rkjnsn wrote:
> On 2017/02/10 22:25:13, Sergey Ulanov wrote:
> > Instead of adding new policy can we just extend RemoteAccessHostDomain to
> allow
> > comma-separate list of domains?
> > 
> > Same question about RemoteAccessHostClientDomainList
> 
> Personally, I don't like the idea of parsing our own list from a string field
> when policies support list fields. We could do it, but I don't like it.

I agree it's not ideal, but having two policies for the same feature seems worse
(particularly because it greatly complicates the code that handles these
policies).

[pastarmovj, 2017-02-13 08:20:36]

On 2017/02/11 01:03:48, Sergey Ulanov wrote:
> +bartfab, pastarmovj
> Bartosz, Julian, is there a better way to upgrade an existing policy from
string
> to a list of strings?
> 
>
https://codereview.chromium.org/2682473003/diff/1/components/policy/resources...
> File components/policy/resources/policy_templates.json (right):
> 
>
https://codereview.chromium.org/2682473003/diff/1/components/policy/resources...
> components/policy/resources/policy_templates.json:861: 'name':
> 'RemoteAccessHostDomainList',
> On 2017/02/11 00:50:11, rkjnsn wrote:
> > On 2017/02/10 22:25:13, Sergey Ulanov wrote:
> > > Instead of adding new policy can we just extend RemoteAccessHostDomain to
> > allow
> > > comma-separate list of domains?
> > > 
> > > Same question about RemoteAccessHostClientDomainList
> > 
> > Personally, I don't like the idea of parsing our own list from a string
field
> > when policies support list fields. We could do it, but I don't like it.
> 
> I agree it's not ideal, but having two policies for the same feature seems
worse
> (particularly because it greatly complicates the code that handles these
> policies).

What you have done is the right path - changing an existing policy is indeed a
very bad idea and we explicitly disallow this. 

What you should do is to mark the old non-list policies as deprecated and
document the new List versions should be used instead (in
policy_templates.json). Then write a deprecating policy handler (see
https://cs.chromium.org/chromium/src/components/policy/core/browser/configura...
) which can handle the mapping of the old policies to the new ones iff the new
are not set. Check the existing deprecating policy handlers for an example how
to write yours. Then you can change your code to only handle the new policy type
(so complex logic there). 

We can then decide for how long (potentially forever :( ) will keep the
deprecated policies around, but from the perspective of your code it won't be an
issue.

[rkjnsn, 2017-04-18 23:09:00]

Description was changed from

==========
Add support for multiple allowed domains

Adds two new policies, RemoteAccessHostDomainList and
RemoteAccessHostClientDomainList, which allow specifying a list of
allowed domains.

BUG=624620
==========

to

==========
Add support for multiple allowed domains

Adds two new policies, RemoteAccessHostDomainList and
RemoteAccessHostClientDomainList, which allow specifying a list of
allowed domains. Deprecates the existing RemoteAccessHostDomain and
RemoteAccessHostClientDomain policies.

BUG=624620
==========

[rkjnsn, 2017-04-18 23:09:00]

rkjnsn@chromium.org changed reviewers:
- bartfab@chromium.org, pastarmovj@chromium.org

[rkjnsn, 2017-04-18 23:11:23]

The CQ bit was checked by rkjnsn@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2017-04-18 23:12:00]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[Jamie, 2017-04-19 00:29:02]

https://codereview.chromium.org/2682473003/diff/20001/remoting/host/it2me/it2...
File remoting/host/it2me/it2me_host.cc (right):

https://codereview.chromium.org/2682473003/diff/20001/remoting/host/it2me/it2...
remoting/host/it2me/it2me_host.cc:179: for (const std::string& domain :
required_host_domain_list_) {
Can this be "const auto&"?

https://codereview.chromium.org/2682473003/diff/20001/remoting/host/it2me/it2...
remoting/host/it2me/it2me_host.cc:332:
UpdateHostDomainListPolicy(std::move(host_domain_list_vector));
Don't need move() if you pass by const reference.

https://codereview.chromium.org/2682473003/diff/20001/remoting/host/it2me/it2...
remoting/host/it2me/it2me_host.cc:528: for (const std::string& domain :
required_client_domain_list_) {
auto?

https://codereview.chromium.org/2682473003/diff/20001/remoting/host/it2me/it2...
File remoting/host/it2me/it2me_host.h (right):

https://codereview.chromium.org/2682473003/diff/20001/remoting/host/it2me/it2...
remoting/host/it2me/it2me_host.h:141: void
UpdateHostDomainListPolicy(std::vector<std::string> host_domain_list);
Pass by const reference, please.

https://codereview.chromium.org/2682473003/diff/20001/remoting/host/policy_wa...
File remoting/host/policy_watcher.cc (right):

https://codereview.chromium.org/2682473003/diff/20001/remoting/host/policy_wa...
remoting/host/policy_watcher.cc:270: }
Does the existing PolicyWatcher test code cover this?

[commit-bot: I haz the power, 2017-04-19 00:31:26]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2017-04-19 00:31:26]

Dry run: This issue passed the CQ dry run.

[rkjnsn, 2017-04-19 16:45:26]

https://codereview.chromium.org/2682473003/diff/20001/remoting/host/it2me/it2...
File remoting/host/it2me/it2me_host.cc (right):

https://codereview.chromium.org/2682473003/diff/20001/remoting/host/it2me/it2...
remoting/host/it2me/it2me_host.cc:179: for (const std::string& domain :
required_host_domain_list_) {
On 2017/04/19 00:29:02, Jamie wrote:
> Can this be "const auto&"?

If you think that's more readable.

https://codereview.chromium.org/2682473003/diff/20001/remoting/host/policy_wa...
File remoting/host/policy_watcher.cc (right):

https://codereview.chromium.org/2682473003/diff/20001/remoting/host/policy_wa...
remoting/host/policy_watcher.cc:270: }
On 2017/04/19 00:29:02, Jamie wrote:
> Does the existing PolicyWatcher test code cover this?

It's getting exercised by the It2MeHost tests, but it probably makes sense to
add an explicit test in the PolicyWatcher tests.

[Jamie, 2017-04-19 16:55:47]

https://codereview.chromium.org/2682473003/diff/20001/remoting/host/it2me/it2...
File remoting/host/it2me/it2me_host.cc (right):

https://codereview.chromium.org/2682473003/diff/20001/remoting/host/it2me/it2...
remoting/host/it2me/it2me_host.cc:179: for (const std::string& domain :
required_host_domain_list_) {
On 2017/04/19 16:45:26, rkjnsn wrote:
> On 2017/04/19 00:29:02, Jamie wrote:
> > Can this be "const auto&"?
> 
> If you think that's more readable.

Being explicit about the type doesn't add to readability, and I think auto is
encouraged where applicable. I don't feel strongly about it though.

[rkjnsn, 2017-04-19 18:24:06]

https://codereview.chromium.org/2682473003/diff/20001/remoting/host/it2me/it2...
File remoting/host/it2me/it2me_host.cc (right):

https://codereview.chromium.org/2682473003/diff/20001/remoting/host/it2me/it2...
remoting/host/it2me/it2me_host.cc:179: for (const std::string& domain :
required_host_domain_list_) {
On 2017/04/19 16:55:47, Jamie wrote:
> On 2017/04/19 16:45:26, rkjnsn wrote:
> > On 2017/04/19 00:29:02, Jamie wrote:
> > > Can this be "const auto&"?
> > 
> > If you think that's more readable.
> 
> Being explicit about the type doesn't add to readability, and I think auto is
> encouraged where applicable. I don't feel strongly about it though.

The style guide says it is "permitted when it increases readability", and
especially should be used to replace long, cluttery types (like iterators) and
when iterating over a map. Otherwise, it seems to leave it up to the author's
and reviewer's discretion. I'll go ahead and use auto here.

https://codereview.chromium.org/2682473003/diff/20001/remoting/host/it2me/it2...
remoting/host/it2me/it2me_host.cc:332:
UpdateHostDomainListPolicy(std::move(host_domain_list_vector));
On 2017/04/19 00:29:02, Jamie wrote:
> Don't need move() if you pass by const reference.

True, but that would guarantee that that vector would need to be copied by
UpdateHostDomainListPolicy, while here we can just pass it ownership of our
vector, which we don't need anymore. In general, the idea is that taking an
object by value when one wants to take ownership means the caller gets to decide
if they want to transfer ownership of an existing object or make a copy, while
taking a constant reference means that the callee must make a copy, even if the
caller was done with the object.

I found some discussion of this on the Chromium mailing list, but it didn't seem
to come to any conclusion. I'm happy to do whatever the team prefers, since
there isn't any real performance consideration here (and there probably isn't in
most cases).

(I've had this discussion once before, but it was in regards to strings, which
*do* have a codified convention for passing by const ref, so I wasn't sure if
that would apply here with a different type.)

[Jamie, 2017-04-19 19:21:06]

https://codereview.chromium.org/2682473003/diff/20001/remoting/host/it2me/it2...
File remoting/host/it2me/it2me_host.cc (right):

https://codereview.chromium.org/2682473003/diff/20001/remoting/host/it2me/it2...
remoting/host/it2me/it2me_host.cc:332:
UpdateHostDomainListPolicy(std::move(host_domain_list_vector));
On 2017/04/19 18:24:06, rkjnsn wrote:
> On 2017/04/19 00:29:02, Jamie wrote:
> > Don't need move() if you pass by const reference.
> 
> True, but that would guarantee that that vector would need to be copied by
> UpdateHostDomainListPolicy, while here we can just pass it ownership of our
> vector, which we don't need anymore. In general, the idea is that taking an
> object by value when one wants to take ownership means the caller gets to
decide
> if they want to transfer ownership of an existing object or make a copy, while
> taking a constant reference means that the callee must make a copy, even if
the
> caller was done with the object.
> 
> I found some discussion of this on the Chromium mailing list, but it didn't
seem
> to come to any conclusion. I'm happy to do whatever the team prefers, since
> there isn't any real performance consideration here (and there probably isn't
in
> most cases).
> 
> (I've had this discussion once before, but it was in regards to strings, which
> *do* have a codified convention for passing by const ref, so I wasn't sure if
> that would apply here with a different type.)

Thanks for the detailed follow-up. I am happy for you to leave these as
pass-by-value if no-one else objects.

[rkjnsn, 2017-04-19 22:58:01]

Patchset #3 (id:40001) has been deleted

[rkjnsn, 2017-04-19 23:13:24]

I made some changes based on feedback, fixed a couple of errors I noticed, and
added some tests to directly test the deprecation logic in PolicyWatcher.

https://codereview.chromium.org/2682473003/diff/60001/remoting/host/policy_wa...
File remoting/host/policy_watcher_unittest.cc (right):

https://codereview.chromium.org/2682473003/diff/60001/remoting/host/policy_wa...
remoting/host/policy_watcher_unittest.cc:82:
multiple_host_domains.AppendString("a.com");
I could make "a.com", et cetera constants. I didn't here because they're only
used once to initialize members that get used as quasi-constants, anyway, but I
don't really have a preference.

https://codereview.chromium.org/2682473003/diff/60001/remoting/host/policy_wa...
remoting/host/policy_watcher_unittest.cc:174:
deprecated_policies_.SetString(key::kRemoteAccessHostDomain, kHostDomain);
I mainly just added stuff to the end of the relevant section. I'm not sure if
there's an organization that I'm missing.

[Sergey Ulanov, 2017-04-20 00:42:55]

The new approach does look cleaner. I have couple of comments about base::Value
handling, but otherwise this change looks rather good.

https://codereview.chromium.org/2682473003/diff/20001/remoting/host/remoting_...
File remoting/host/remoting_me2me_host.cc (right):

https://codereview.chromium.org/2682473003/diff/20001/remoting/host/remoting_...
remoting/host/remoting_me2me_host.cc:1130: if
(!policies->GetList(policy::key::kRemoteAccessHostClientDomainList,
This will return false if the policy is there, but it's not a list. I think we
want to treat that case as a policy error, see OnPolicyError().

https://codereview.chromium.org/2682473003/diff/60001/remoting/host/it2me/it2...
File remoting/host/it2me/it2me_host.cc (right):

https://codereview.chromium.org/2682473003/diff/60001/remoting/host/it2me/it2...
remoting/host/it2me/it2me_host.cc:330:
host_domain_list_vector.push_back(value.GetString());
GetString() is allowed only when the value is actually a string. Can we be sure
that host_domain_list contains only strings? If not then I think you want to use
GetAsString()

[rkjnsn, 2017-04-20 00:58:26]

https://codereview.chromium.org/2682473003/diff/20001/remoting/host/remoting_...
File remoting/host/remoting_me2me_host.cc (right):

https://codereview.chromium.org/2682473003/diff/20001/remoting/host/remoting_...
remoting/host/remoting_me2me_host.cc:1130: if
(!policies->GetList(policy::key::kRemoteAccessHostClientDomainList,
On 2017/04/20 00:42:54, Sergey Ulanov wrote:
> This will return false if the policy is there, but it's not a list. I think we
> want to treat that case as a policy error, see OnPolicyError().

My understanding is that Schema::Normalize (which we call in PolicyWatcher)
should ensure that this is, in fact, a list. I can test, though, to double
check.

https://codereview.chromium.org/2682473003/diff/60001/remoting/host/it2me/it2...
File remoting/host/it2me/it2me_host.cc (right):

https://codereview.chromium.org/2682473003/diff/60001/remoting/host/it2me/it2...
remoting/host/it2me/it2me_host.cc:330:
host_domain_list_vector.push_back(value.GetString());
On 2017/04/20 00:42:55, Sergey Ulanov wrote:
> GetString() is allowed only when the value is actually a string. Can we be
sure
> that host_domain_list contains only strings? If not then I think you want to
use
> GetAsString()

Similarly, I believe Schema::Normalize should ensure that the list items are the
correct type.

[Sergey Ulanov, 2017-04-20 18:51:17]

lgtm

[rkjnsn, 2017-04-21 23:32:33]

rkjnsn@chromium.org changed reviewers:
+ pastarmovj@chromium.org

[rkjnsn, 2017-04-21 23:32:34]

Julian, can you review the policy additions?

Thanks.

[pastarmovj, 2017-04-24 13:06:34]

I have only one suggestion about a cleaner way to handle the policy deprecation
other wise it seems fine to me.

https://codereview.chromium.org/2682473003/diff/60001/remoting/host/policy_wa...
File remoting/host/policy_watcher.h (right):

https://codereview.chromium.org/2682473003/diff/60001/remoting/host/policy_wa...
remoting/host/policy_watcher.h:105: void
HandleDeprecatedPolicies(base::DictionaryValue* dict);
In order to not reinvent the wheel can you try to write a 
LegacyPoliciesDeprecatingPolicyHandler that will do the same thing
https://cs.chromium.org/chromium/src/components/policy/core/browser/configura...
or if this one is too limiting a regular SimplePolicyHandler.

This way you can even completely remove the old prefs in favor of only the new
ones and get the same effect with simpler client code.

[rkjnsn, 2017-04-24 17:20:48]

https://codereview.chromium.org/2682473003/diff/60001/remoting/host/policy_wa...
File remoting/host/policy_watcher.h (right):

https://codereview.chromium.org/2682473003/diff/60001/remoting/host/policy_wa...
remoting/host/policy_watcher.h:105: void
HandleDeprecatedPolicies(base::DictionaryValue* dict);
On 2017/04/24 13:06:34, pastarmovj wrote:
> In order to not reinvent the wheel can you try to write a 
> LegacyPoliciesDeprecatingPolicyHandler that will do the same thing
>
https://cs.chromium.org/chromium/src/components/policy/core/browser/configura...
> or if this one is too limiting a regular SimplePolicyHandler.
> 
> This way you can even completely remove the old prefs in favor of only the new
> ones and get the same effect with simpler client code.

Unfortunately, I don't believe we can use
LegacyPoliciesDeprecatingPolicyHandler. Chrome Remote Desktop reads and
processes the policy directly, rather than using PolicyHandlers to load them
into prefs.

[pastarmovj, 2017-04-27 06:22:51]

On 2017/04/24 17:20:48, rkjnsn wrote:
>
https://codereview.chromium.org/2682473003/diff/60001/remoting/host/policy_wa...
> File remoting/host/policy_watcher.h (right):
> 
>
https://codereview.chromium.org/2682473003/diff/60001/remoting/host/policy_wa...
> remoting/host/policy_watcher.h:105: void
> HandleDeprecatedPolicies(base::DictionaryValue* dict);
> On 2017/04/24 13:06:34, pastarmovj wrote:
> > In order to not reinvent the wheel can you try to write a 
> > LegacyPoliciesDeprecatingPolicyHandler that will do the same thing
> >
>
https://cs.chromium.org/chromium/src/components/policy/core/browser/configura...
> > or if this one is too limiting a regular SimplePolicyHandler.
> > 
> > This way you can even completely remove the old prefs in favor of only the
new
> > ones and get the same effect with simpler client code.
> 
> Unfortunately, I don't believe we can use
> LegacyPoliciesDeprecatingPolicyHandler. Chrome Remote Desktop reads and
> processes the policy directly, rather than using PolicyHandlers to load them
> into prefs.

Hey sorry I missed to reply here. It's ok as it is. I just wanted to save some
code duplication which in this case seems impossible. lgtm.

[rkjnsn, 2017-04-28 17:45:10]

The CQ bit was checked by rkjnsn@chromium.org

[rkjnsn, 2017-04-28 17:45:10]

The patchset sent to the CQ was uploaded after l-g-t-m from
sergeyu@chromium.org, pastarmovj@chromium.org
Link to the patchset: https://codereview.chromium.org/2682473003/#ps80001
(title: "Rebase patch")

[commit-bot: I haz the power, 2017-04-28 17:45:39]

CQ is trying da patch.

Follow status at:
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2017-04-28 17:59:20]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2017-04-28 17:59:21]

Try jobs failed on following builders:
  chromium_presubmit on master.tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/chromium_presub...)

[rkjnsn, 2017-04-28 18:08:59]

rkjnsn@chromium.org changed reviewers:
+ jwd@chromium.org
- jamiewalch@chromium.org, pastarmovj@chromium.org, sergeyu@chromium.org

[rkjnsn, 2017-04-28 18:09:00]

Jesse,

Can you review the histogram changes?

Thanks.

[rkjnsn, 2017-04-28 19:04:44]

rkjnsn@chromium.org changed reviewers:
+ isherman@chromium.org
- jwd@chromium.org

[rkjnsn, 2017-04-28 19:04:45]

Oops. I guess Jesse is OOO.

Ilya,

Can you take a look at the histogram changes?

Thanks.

[Ilya Sherman, 2017-04-28 20:56:21]

histograms.xml lgtm

[rkjnsn, 2017-04-28 21:01:16]

The CQ bit was checked by rkjnsn@chromium.org

[commit-bot: I haz the power, 2017-04-28 21:02:15]

CQ is trying da patch.

Follow status at:
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2017-04-28 22:04:05]

CQ is committing da patch.

Bot data: {"patchset_id": 80001, "attempt_start_ts": 1493413276416910,
"parent_rev": "7086194f028b6a0d0740e816bd4a84817726def8", "commit_rev":
"10cd268f54d5f567b8834838ad0726e35dcdbe51"}

[commit-bot: I haz the power, 2017-04-28 22:04:18]

Description was changed from

==========
Add support for multiple allowed domains

Adds two new policies, RemoteAccessHostDomainList and
RemoteAccessHostClientDomainList, which allow specifying a list of
allowed domains. Deprecates the existing RemoteAccessHostDomain and
RemoteAccessHostClientDomain policies.

BUG=624620
==========

to

==========
Add support for multiple allowed domains

Adds two new policies, RemoteAccessHostDomainList and
RemoteAccessHostClientDomainList, which allow specifying a list of
allowed domains. Deprecates the existing RemoteAccessHostDomain and
RemoteAccessHostClientDomain policies.

BUG=624620

Review-Url: https://codereview.chromium.org/2682473003
Cr-Commit-Position: refs/heads/master@{#468149}
Committed:
https://chromium.googlesource.com/chromium/src/+/10cd268f54d5f567b8834838ad07...
==========

[commit-bot: I haz the power, 2017-04-28 22:04:20]

Committed patchset #4 (id:80001) as
https://chromium.googlesource.com/chromium/src/+/10cd268f54d5f567b8834838ad07...

[Thiemo Nagel, 2017-05-17 14:18:08]

tnagel@chromium.org changed reviewers:
+ tnagel@chromium.org

[Thiemo Nagel, 2017-05-17 14:18:09]

https://codereview.chromium.org/2682473003/diff/80001/components/policy/resou...
File components/policy/resources/policy_templates.json (right):

https://codereview.chromium.org/2682473003/diff/80001/components/policy/resou...
components/policy/resources/policy_templates.json:778: 'desc': '''This policy is
deprecated. Please use RemoteAccessHostClientDomainList instead.''',
(here and below)

Note that quoting a policy name requires it to be enclosed in <ph ...> to mark
it as untranslatable, cf. top of the file.