Unable to reproduce this issue on reported version 64.0.3282.140 using Mac 10.13.3 with steps mentioned below.

1. Setup proxy which asks for authentication.
2. Opened chrome://settings and clicked on sign in button -- provided proxy credentials.
3. Now in sign in form provided valid credentials and able to login successfully.

Attaching screencast for reference. 

@Reporter: Please check the video and let us know if we miss anything. If possible please guide us with a video. This would help in further triaging of the issue.

Thanks!

Deleted: 811643.mp4 1.1 MB

	811643.mp4 1.1 MB View Download

Hi Sindhu, 
Thanks for checking. My apologises for the confusion. The proxy on my network doesn't have the "proxy authentication" protocol. 
What it does is, redirect the user via 302 to an HTML login page, on which we add our credentials. This is on a corporate network, and something not publicly available, unfortunately. However, a "simulation" of that behaviour is captured using Fiddler and setting up an auto-responder that sends a 302 to a different page. Please see the attached gif. 
If you need, I can also share the pre ver-64 behaviour. Also note this is not specific to Mac/Win. This behaviour is reproducible on both.

Thanks.

Deleted: chrome profile login.gif 761 KB

	chrome profile login.gif 761 KB View Download

Thank you for providing more feedback. Adding requester "sindhu.chelamcherla@chromium.org" to the cc list and removing "Needs-Feedback" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Hoes does the proxy handle SSL tunnel requests?  Does it use a man-in-the-middle cert to hijack SSL requests, or does it send a 302 redirect in response to the CONNECT request (I'm assuming it's an HTTP proxy, and not SOCKS oR HTTPS?).  If it does use its own cert, is the cert locally trusted, or do you have to normally click through a self-signed cert warning page?

It is an HTTPS & man-in-the-middle proxy. Hence, all machines in our corporate network have our cert installed and trusted.

And when does it send the redirect in response to HTTPS requests - when establishing the HTTPS tunnel, or after?  Could you provide us with a net-export log (Can you open net-export before triggering the problematic behavior?)

Punting back into the main network triage queue - I think this is more likely an SSL/cert issue than a proxy one.

Instructions for net-export:  https://dev.chromium.org/for-testers/providing-network-details

Redirect is not sent on the CONNECT, but on the main request - which in this case is GET `https://accounts.google.com/embedded/setupchrome/usermenu?...`

This flow works fine in the main browser window. It doesn't work for the chrome browser login. I'll share the net-export logs shortly.

Please find attached.

Deleted: chrome-net-export-log.json 1.9 MB

chrome-net-export-log.json 1.9 MB View Download

Hi Sabine,

Can you take a look at this? 

As TE team doesn't have mentioned proxy setup in comment#4, it will not be possible to check this issue from our end. Hence adding TE-NeedsTriageHelp label for further investigation of net log attached in comment#11 from Internals>Network team.

Thanks!

Hi Sidhu, to help reproduce you could possible use any network tool like fiddler to intercept the request and send an HTTP 302. The page won't load and end up in the screenshot I shared in my original description. 

Thanks.

It looks like something is broken in the Chrome browser sign-in flow. I'll take a look at the bug.

I have tried for about 4 hours today to get a Fiddler config that actually redirects the HTTPS traffic to accounts.google.com to a 302 response to drive as suggested in comment $3. I could not make it work though.

See my Fiddler config in the attached screenshots.

The contents of the redirect_90.txt file are (also attached):
HTTP/1.1 302 Found
Content-Length: 0
Location: https://drive.google.com
Date: Mon, 20 Feb 2018 15:10:53 GMT

From Fiddler I can see that there is traffic going to accounts.google.com, but it does not look like it is intercepted and redirected in any way.

wahaj.ali@elastica.co:
1. Is there some additional configuration that I need to add to Fiddler? Could you please take screenshots of all changes needed that I need do in Fiddler?
2. Could you try opening the URL chrome://chrome-signin/?access_point=10&reason=0&constrained=1 in a tab. Does this work?

Deleted: fiddler_config.PNG 58.9 KB

	fiddler_config.PNG 58.9 KB View Download

Deleted: fiddler_config_test_url.PNG 69.8 KB

	fiddler_config_test_url.PNG 69.8 KB View Download

Deleted: response_90.txt 112 bytes

response_90.txt 112 bytes View Download

@msarda@chromium.org from the screenshot it seems that you have not enabled SSL decryption, without which autoresponder won't work, as the whole URL is not available in the CONNECT request. Here is documentation that might help: 
http://docs.telerik.com/fiddler/Configure-Fiddler/Tasks/FirefoxHTTPS

Essentially, you'll need to enable HTTPS decryption and import the root CA.

Hope that helps. If not, I can share more screenshots of my config.

Thanks.

I did not have time to look at this bug today and tomorrow I am OOO.

Also, before I can actually investigate further the bug I am trying to see if I using a Fiddler CA on my corp machine is acceptable for security or no.

wahaj.ali@elastica.co: Could you try opening the URL chrome://chrome-signin/?access_point=10&reason=0&constrained=1 in a tab. Does this work?

msarda: I'm removing Internals>Network but please add back if you think this is a net stack problem.

@msarda@chromium.org: I am seeing the same behaviour as before when accessing `chrome://chrome-signin/?access_point=10&reason=0&constrained=1` directly. Please see the attached GIF.

Another thing that I noticed in the response_90.txt that you shared, you need to add couple of new lines at the end of header. I have attached the file I used for response. 

Deleted: chrome profile login-1.gif 1.8 MB

	chrome profile login-1.gif 1.8 MB View Download

Deleted: 90_Response.txt 114 bytes

90_Response.txt 114 bytes View Download

I managed to reproduce the infinite loop after the redirect.

Notes: I do not get the infinite loop if I use the is_constrained=0 parameter in the chrome://chrome-signin URL:
chrome://chrome-signin/?access_point=10&reason=0&constrained=0&auto_close=1&showAccountManagement=1&force_keep_data=1

We deprecated this in M64 as it was using an old Google server endpoint for sync that is considered less secure.

As explained above, in M64 we had to deprecate the usage of the old Google auth endpoint for signing in. This impact you as I think you are using an unusual configuration. Let me explain in detail what I think happens here:

In M63 and before:
1. User attempts to sign in to Chrome.
2. Chrome open the sign-in modal dialog and loads "https://accounts.google.com/embedded/setup/chrome/usermenu?client_id=<xxxx>&hl=en-US&source=chrome&flow=signin"
3. Proxy does a 302 redirect.
4. Chrome loads the legacy full-page sign-in, which loads "https://accounts.google.com/ServiceLogin?skipvpage=true&sarp=1&rm=hide&continue=chrome-extension%3A%2F%2Fmfffpogegjflfpflabcdkioaeobkgjik%2Fsuccess.html%3Faccess_point%3D10%26source%3D13&service=chromiumsync&hl=en-US"
5. Load is successful as this is not blocked by your proxy config

In M64:
1. User attempts to sign in to Chrome.
2. Chrome open the sign-in modal dialog and loads "https://accounts.google.com/embedded/setup/chrome/usermenu?client_id=<xxxx>&hl=en-US&source=chrome&flow=signin"
3. Proxy does a 302 redirect.
4. Chrome loads the new full-page sign-in, which loads "https://accounts.google.com/embedded/setup/chrome/usermenu?client_id=<xxxx>&hl=en-US&source=chrome&flow=signin"
3. Proxy does a 302 redirect so this page fails to load.

Note that in M65 we plan to launch a different sign-in flow that happens entirely on the web (it will be rolled out gradually though, so it may take time until is gets to all users). I expect this will not require any special additional configuration as it does not use a separated cookie, certificate storage.

wahaj.ali@elastica.co: Could you configure your proxy to allow the user to load the second request to https://accounts.google.com/embedded/setup/chrome/usermenu?client_id=<xxxx>&hl=en-US&source=chrome&flow=signin instead of always doing a 302 redirect?

@msarda@chromium.org:
Slight addition in the flow you have described: 

In M63 and before:
After the legacy full-page sign-in page opens (step 4), we redirect the user again. User goes to our corporate portal, signs-in, is redirected back to the legacy full-page sign in and is henceforth able to sign in to chrome.

I also tested with "constrained=0" like you suggested and that seems to work fine.

I'm not sure if I can allow our proxy to bypass the second request, since the first and second request in M64 are the same. How can I differentiate the two?

There is no difference between the 2 URLs - we are loading the same URL the second time, we just need to load it in a full tab (because we may need to redirect to a SAML ID provider and we cannot do that in a dialog).

I still do not understand how this worked in M63 - the 2 URLs on the full tab page were not the same (I would expect them to be the same)? In my test, if I redirect for the legacy URL using the same Fiddler config, the legacy page is also blocked and does not load.

@msarda@chromium.org Regarding the new flow that you mentioned for ver 65, can you tell if all users who move to that version will get the updated flow. I tested with following 3 versions of Google Chrome, and only found the new flow in one of them:

Version 65.0.3325.181 (Official Build) (64-bit) (old flow)
Version 66.0.3359.33 (Official Build) beta (64-bit) (old flow)
Version 67.0.3371.0 (Official Build) dev (32-bit) (new flow)

Is this due to some versioning difference b/w Chromium and Google Chrome?

As this is a big change, we are rolling it out gradually with a server-side configured experiment. To test it on M65 (at this point I strongly discourage asking you to ask users to enable it):
1. Open chrome://flags/#account-consistency
2. Select from the drop-down menu "Enabled Dice (prepare migration, Chrome sync endpoint)"
3. Restart Chrome
4. Attempt to sign in to Chrome and let me know if that works.

I will update this ticket with the results of our stable experiment and I will let you when we plan to roll it out to 100% of stable users.

Signin Bug Triage: Mihai, is there any update on this? Should we close this (or bump to P2)?

Nope, this still needs to be assigned. I'm waiting for our experiment to roll out to be able to report back on the bug.

Do you plan on addresing this anytime soon?  It would appear that the defect has stalled.

I have customer awaiting resolution on this.

Thanks for any update you can provide.
Mike

We are rolling out the experiment mentioned at comment #21 now (it is currently at 1% of stable). We expect it to be fully rolled out in a couple of weeks (this may be delayed if we find any issue during the experiment). I'll update back the bug once it rolls out to 100%.

Signin triage: any updates on this?

We have rolled out the aforementioned experiment to 100% on stable. This should be fixed now.

wahaj.ali@elastica.co: Could you please retest and tell me if you can still reproduce the issue?