Thanks for the report.

Did you see the same procedure worked in prior version of Chrome (e.g. M60),
while you see it is not working in M61?  Or is it just not what you expect?

Routing to Internals>Network>Auth so if anyone can confirm this is an
expected behavior or not.

I don't really understand the report. If you're talking about typing a URL containing `username:password` in the omnibox, then it's expected not to fail. The changes we made somewhat recently blocked embedded credentials in subresource requests only, not in top-level navigations.

Does that cover what you're reporting?

Hi.
As per https://www.chromestatus.com/feature/5669008342777856 .
says  "We should block requests for subresources that contain embedded credentials (e.g. "http://ima_user:hunter2@example.com/yay.tiff"). Such resources would be handled as network errors."

In my automation script, i tried the same (https://username:password@url.com/geolocation) . As per your recent changes, i should get network error or should not bypass authentication window.

In Simple:
1.passing url without UserName and Password in it. eg) http://url.com/geolocation
  Authentication required Window pop up appears asking for username and password.

2.Passing Url WITH username and pass in it. eg)https://username:password@url.com/geolocation
   Authentication required window pop up doesnt appear or i dont see any error displaying and its bypassing the authentication window. 

This Functionality passing Username and password in url is DROPPED after Chrome V_59.


Other people also reporting same .pls refer demouser123 comment https://sqa.stackexchange.com/questions/29514/how-to-handle-windows-authentication-pop-up-with-protractor

thanks

> As per https://www.chromestatus.com/feature/5669008342777856 .
> says  "We should block requests for subresources that contain
> embedded credentials (e.g. "http://ima_user:hunter2@example.com/yay.tiff").
> Such resources would be handled as network errors."

"Subresources" is an important word in that first sentence. We changed the way things like `<script src="https://username:password@example.com/">` works. We did not change the way top-level navigation works (at least, not intentionally).

If you type `http://username:password@example.com/` into the omnibox, that request will be authenticated if the server requests authentication. If you're using an automation tool like Selenium to instruct the browser to navigate the top-level window, the same applies: we haven't changed the behavior of those navigations.

Is that what we're talking about? Or is `https://username:password@url.com/geolocation` being loaded in an iframe?

OK .
Thanks for the clarification.

@Reporter as per comment #5,It seems you got clarification for this issue, if yes, can we close this?

Thanks!

Yes, Pls go ahead in closing this .

Thank you for providing more feedback. Adding requester "sc00335628@techmahindra.com" to the cc list and removing "Needs-Feedback" label.

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