Properly handle failure modes in the wildcard login check.

Properly handle failure modes in the wildcard login check.

In the case of network failure for the user info fetch, the failing
check will be treated as a negative reply, which is incorrect for the
post-login checks.

BUG=chromium:347081
Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=253627

[Mattias Nissler (ping if slow), 2014-02-26 10:54:26]

*facepalm*, please review.

[Joao da Silva, 2014-02-26 11:10:17]

lgtm to plug the signout bug. More work may be needed to make the whitelist
check reliable, comments inline.

https://codereview.chromium.org/181363002/diff/1/chrome/browser/chromeos/logi...
File chrome/browser/chromeos/login/login_performer.cc (right):

https://codereview.chromium.org/181363002/diff/1/chrome/browser/chromeos/logi...
chrome/browser/chromeos/login/login_performer.cc:366:
delegate_->WhiteListCheckFailed(user_context_.username);
IIUC this means that if the whitelist check returns RESULT_FAILED at sign-in
time then the user can't sign-in, right?

I think that's fine, it's easy to retry and the network shouldn't be changing at
the sign-in screen. Just making sure I follow :-)

https://codereview.chromium.org/181363002/diff/1/chrome/browser/chromeos/poli...
File chrome/browser/chromeos/policy/user_cloud_policy_manager_chromeos.cc
(right):

https://codereview.chromium.org/181363002/diff/1/chrome/browser/chromeos/poli...
chrome/browser/chromeos/policy/user_cloud_policy_manager_chromeos.cc:64: }
If this CL is meant to just fix the signout problem then it's fine.

But we should retry on RESULT_FAILED here, otherwise turning wifi off right
after signing in may skip the whitelist check. RESULT_FAILED may also be a
consistent result for some configurations (user ONC, etc)

[Mattias Nissler (ping if slow), 2014-02-26 11:13:40]

https://codereview.chromium.org/181363002/diff/1/chrome/browser/chromeos/logi...
File chrome/browser/chromeos/login/login_performer.cc (right):

https://codereview.chromium.org/181363002/diff/1/chrome/browser/chromeos/logi...
chrome/browser/chromeos/login/login_performer.cc:366:
delegate_->WhiteListCheckFailed(user_context_.username);
On 2014/02/26 11:10:18, Joao da Silva wrote:
> IIUC this means that if the whitelist check returns RESULT_FAILED at sign-in
> time then the user can't sign-in, right?
> 
> I think that's fine, it's easy to retry and the network shouldn't be changing
at
> the sign-in screen. Just making sure I follow :-)

Correct.

https://codereview.chromium.org/181363002/diff/1/chrome/browser/chromeos/poli...
File chrome/browser/chromeos/policy/user_cloud_policy_manager_chromeos.cc
(right):

https://codereview.chromium.org/181363002/diff/1/chrome/browser/chromeos/poli...
chrome/browser/chromeos/policy/user_cloud_policy_manager_chromeos.cc:64: }
On 2014/02/26 11:10:18, Joao da Silva wrote:
> If this CL is meant to just fix the signout problem then it's fine.
> 
> But we should retry on RESULT_FAILED here, otherwise turning wifi off right
> after signing in may skip the whitelist check. RESULT_FAILED may also be a
> consistent result for some configurations (user ONC, etc)

Remember that this is just a best-effort to get already-created accounts that
would have failed the whitelist check pruned out. I'd like to wait for a
decision on how we want to implement the whitelist check moving forward (as
discussed on the separate mail thread and doc) before tackling reliability here
(and other shortcomings of this hack).

[xiyuan, 2014-02-26 17:27:59]

lgtm

[Mattias Nissler (ping if slow), 2014-02-26 17:33:03]

The CQ bit was checked by mnissler@chromium.org

[commit-bot: I haz the power, 2014-02-26 17:33:22]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/mnissler@chromium.org/181363002/1

[commit-bot: I haz the power, 2014-02-26 23:30:18]

Change committed as 253627