Issue metadata
Sign in to add a comment
|
Auth proxy does not work on Login screen |
||||||||||||||||||||||||
Issue descriptionChrome Version: <From about:version: Google Chrome 70.0.3538.34> Chrome OS Version: <From about:version: 11021.28.0> Chrome OS Platform: Kevin/Eve Please specify Cr-* of the system to which this bug/feature applies (add the label below). Steps To Reproduce: (1)On login screen, connect to auth proxy. (2)Try to add a new user. (3)screen freezes / white screen with "Please wait..". (4)Not getting the authentication screen and unable to add new user. Expected Result: shoudl be authenticated if username password is entered and able to add new users. Actual Result: screen frozen, no authentication page and cannot add a new user How frequently does this problem reproduce? (Always, sometimes, hard to reproduce?) Always NOTE: 1) in current image, auth proxy works fine when used by logged in user. 2) last checked this feature worked fine on 11021.19.0 Cyan.
,
Sep 26
Feedback report@ https://listnr.corp.google.com/report/85687038746
,
Oct 1
This bug does not have an owner and is marked RBS. Please update with the plan and ETA to fix the issue or remove the RBS label if this is no longer a blocker. Thanks.
,
Oct 1
Steven, assigning this to you to get the investigation started. Please take a look. Thanks
,
Oct 1
This is not really my area. Adjusting the components, hopefully someone can triage this properly.
,
Oct 1
,
Oct 1
jmuppala@ to confirm - this is a recent regression? So in 11021.19.0, the AddUser also worked behind a proxy?
,
Oct 1
,
Oct 1
[+asanka]: Might this be related to the cancel vs continue without credentials stuff you're working on?
,
Oct 1
This is broken in both webui and login views; I'm not aware of any recent changes in login code that would have broken this. There's a separate issue in views-login where the dialog that pops up asking for username and password authentication is not rendering correctly, which is why the cancel button is frozen/doesn't work. I'll work on fixing that. I've pulled that off into issue 890976.
,
Oct 1
Could someone point me to the code that makes the request? If so, I could confirm whether the resulting code path involves the accidental prompt dismissal. However, if there was an authentication prompt before, it implies that the request was being made in a way that allowed the requestor to respond to an auth challenge. Issue 874790 affects requests that are made with no support for handling an authentication challenge.
,
Oct 1
> I could confirm whether the resulting code path involves the accidental prompt dismissal. I don't believe repro requires accidental prompt dismissal. With `--show-webui-login`, after authenticating on the restricted network/proxy the UI continued to not load. I believe the login prompt is created by https://cs.chromium.org/chromium/src/chrome/browser/ui/login/login_handler.cc?l=732-748&rcl=5e3bf2a1f618d292d253ee5b0236fcd2cb909c50, though I am not familiar with this code.
,
Oct 1
I was thinking some background request might try to proceed without credentials before the request that triggers the credentials dialog is made (Disclaimer: I have no idea what I'm talking about).
,
Oct 1
Could this have something to do with the Network service being turned on to 50% on non-stable channels?
,
Oct 2
Seeing this on Coral M70-11021.34.0, 70.0.3538.41.
,
Oct 3
Fix for issue 874790 is on ToT as well as Canary 71.0.3569.0. You might try it out there, but I'm pretty sure that's not going to address what's going on here. As mentioned in #11, that issue deals solely with requests made with no support for handling an authentication challenge.
,
Oct 3
,
Oct 3
|
|||||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||||
Comment 1 by jmuppala@chromium.org
, Sep 26