Issue metadata
Sign in to add a comment
|
[OOBE] [LoginScreen] Regular user cannot login through a SSL Whitelist/ Regular/Auth proxy network. |
|||||||||||||||||||||||||||
Issue descriptionChrome Version: <From about:version: Google Chrome 68.0.3440.18> Chrome OS Version: <From about:version: Platform 10718.15.0 > Chrome OS Platform: <Eve> Network info: <Proxy/WiFi> Please specify Cr-* of the system to which this bug/feature applies (add the label below). Steps To Reproduce: (1) On the OOBE screen connect to the locked down proxy network (2) Try to login, as a user. Expected Result: User can login into the device using the locked down network and see "You're signed in!" page(Attachment#3). Actual Result: Blank page after the user enters password for his account. Check Screenshot (Attachment#2). How frequently does this problem reproduce? (Always, sometimes, hard to reproduce?) Always What is the impact to the user, and is there a workaround? If so, what is it? Cannot sign in using locked down network. Please provide any additional information below. Attach a screen shot or log if possible. For graphics-related bugs, please copy/paste the contents of the about:gpu page at the end of this report.
,
Jun 8 2018
I confirm this issue with a user sign in, however there is no such problem with enterprise enrollment and following user sign in: (1) On the OOBE screen connect to the locked down proxy network (2) Press Ctrl+Alt+E and enroll device to domain (3) Login as a user No issues. Chrome OS: 10718.16.0 Chrome: 68.0.3440.18 Device: Reks
,
Jun 11 2018
We are trying to go to beta this week, we need this fixed in the next 24 hours.
,
Jun 11 2018
+stevenjb
,
Jun 11 2018
I'm Gardening this week and I'm not super familiar with the actual login screens. The "expected" screenshot is post login, not part of OOBE as far as I am aware.
,
Jun 11 2018
,
Jun 11 2018
,
Jun 11 2018
aashutoshk@/ibezmenov@ Could you provide more details on what is "locked down proxy network"? Is this a proxy that requires username+password authentication, or something else? Is the network and the proxy configured manually, or is it configured via PAC (proxy auto-config script), or is it setup via policy? As a note, I see a recent bug 849128 which seems to indicate that the browser test for authenticated proxies on the login screen got broken. Maybe it's related.
,
Jun 11 2018
Could you provide more details on what is "locked down proxy network"? >> All the network traffic blocked except hostnames listed at https://support.google.com/chrome/a/answer/6334001?hl=en Is this a proxy that requires username+password authentication, or something else? >> No this configuration does not need username and password. Is the network and the proxy configured manually, or is it configured via PAC (proxy auto-config script), or is it setup via policy? >> Manually set in OOBE.
,
Jun 12 2018
aashutoshk@ - please check on M67 as well.
,
Jun 12 2018
This happens on M67 also. Candy 10575.55.0. Will check on M66 and update. Feedback report: https://listnr.corp.google.com/report/85496500592
,
Jun 13 2018
We're already in stable for M67. Is this significant enough to halt the push for all boards? Or was this tagged as RBS as a priority indicator rather than a push impact? Please call RBS issues to the TPM's attention over IM this late in the workflow.
,
Jun 13 2018
,
Jun 13 2018
Finding from the testing, 1) This issue does NOT happen for the enterprise user if the locked down proxy network policy is pushed through the Cpanel. 2) Only if the regular user configures and connects to locked down proxy network locally, we see a blank page instead of "You're signed in!" page. There is a workaround; the user can reboot to use the device.
,
Jun 13 2018
Let us still bisect this and fix this.
,
Jun 13 2018
,
Jun 16 2018
Good Build:10452.38.0 Bad Build: 10452.51.0 Diff : https://crosland.corp.google.com/log/10452.38.0..10452.51.0 https://chromium.googlesource.com/chromium/src/+log/66.0.3359.71..66.0.3359.92?n=10000
,
Jun 16 2018
Thank you Aashuthosh! This is going to be super helpful.
,
Jun 18 2018
So, to be clear - this isn't an issue with enrollment, because enrollment succeeds. This is a bug where you try to use the device *as a consumer device* with some kind of restrictive proxy in place during OOBE? If so, we should remove the Enterprise>Enrollment label.
,
Jun 19 2018
,
Jun 23 2018
,
Jun 25 2018
We see this issue while trying to login using the regular or auth proxy. R67-10575.58.0 Comment#17 applies here also.
,
Aug 1
Still reproducible. Eve R68-10718.71.0
,
Aug 6
Removing Enterprise flag. Comment #17 *literally* demonstrates that this is a regression, so not sure why this keeps getting reverted to a regular Type-Bug, but not gonna get involved in an edit war on this.
,
Aug 6
,
Aug 20
Reproducible in R68- 10718.88.0
,
Sep 7
Seeing this on R69-10895.49.0, 69.0.3497.87 Kevin. Able to reproduce on OOBE and login screen.
,
Oct 17
Seeign this on Kevin , R70-11021.51.0, 70.0.3538.69
,
Oct 24
This is reproducible on Nocturne M71-11151.11.0. Adding M71 label to the issue.
,
Dec 12
Nocturne M72-11316.18.0 |
||||||||||||||||||||||||||||
►
Sign in to add a comment |
||||||||||||||||||||||||||||
Comment 1 by aashuto...@chromium.org
, Jun 8 2018Components: OS>Systems>Network Enterprise