New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 7 users

Issue metadata

Status: Duplicate
Merged: issue 123150
Owner: ----
Closed: Jun 2012
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 2
Type: Bug

Restricted
  • Only users with Commit permission may comment.



Sign in to add a comment
link

Issue 128902: HTTP Basic Auth user/pass in URL not respected

Reported by dgarr...@chromium.org, May 20 2012 Project Member

Issue description

Chrome Version     :  19.0.1084.46 m (I know it works in R18)
OS Version         :  Win 7/OS X/Chrome OS

What steps will reproduce the problem?

1. Open a URL with a valid embedded http auth username/password of the form:

http://user:password@hostname/

What is the expected output?

That I will be authenticated to hostname using username/password.

What do you see instead?

I receive a prompt to enter username/password for this host.

How frequently does this problem reproduce? (Always, sometimes, hard to
reproduce?)

100% broken in R19, never in R18 or before using the same bookmark.

What is the impact to the user, and is there a workaround? If so, what is
it?

It's an obscure behavior, but it's an old standard and we shouldn't break it without good reason. In my case, it allows me to have URLs that auto-login with guest access to some fairly stupid IP cameras without prompting the user.
 

Comment 1 by Deleted ...@, May 21 2012

full ack!

Comment 2 by ksta...@gmail.com, May 30 2012

I am seeing this behavior in both google-chrome-stable-19.0.1084.46-135956.x86_64 and google-chrome-beta-20.0.1132.17-138701.x86_64 releases.

It's breaking an internal web page I have that passes credentials to items loaded on a page via Javascript.

Comment 3 by dharani@google.com, May 31 2012

Cc: wtc@chromium.org
Labels: Action-BisectNeeded

Comment 4 by wtc@chromium.org, Jun 1 2012

Cc: asanka@chromium.org
dgarrett, asanka: do you have time to perform a bisection to track down
the commit that introduced this regression?  Thanks.

Comment 5 by asanka@chromium.org, Jun 1 2012

Mergedinto: 123150
Status: Duplicate
This is a duplicate of  issue 123150 . It should be fixed in stable from version 19.0.1084.52+, and in beta from version 20.0.1132.19+.

Comment 6 by cbentzel@chromium.org, Jun 1 2012

Note - we still plan to revert support for embedded auth credentials in URLs for a number of security reasons. The reason this behavior was re-enabled is that it had unintend collateral damage on XmlHttpRequest username/password fields.

Comment 7 by cott...@gmail.com, Jun 1 2012

You've got to be kidding me. Advanced setting, please!

Comment 8 by ksta...@gmail.com, Jun 1 2012

If that's done, how do you propose I would embed several images on a page from remote web servers that require HTTP authentication?  It's simply not possible to disable the auth requirement on that side due to proprietary hardware.

-1 to this change!

Comment 9 by dgarr...@chromium.org, Jun 1 2012

That's exactly my situation, trying to embed images from a cheap IP camera in a web page. I have no control over the software on the IP camera, only it's configuration.

I'm surprised this is a security issue since so very few sites (especially modern ones) use HTTP Auth.

Comment 10 by bugdroid1@chromium.org, Oct 13 2012

Project Member
Labels: Restrict-AddIssueComment-Commit
Mergedinto: chromium:123150
This issue has been closed for some time. No one will pay attention to new comments.
If you are seeing this bug or have new data, please click New Issue to start a new bug.

Comment 11 by bugdroid1@chromium.org, Mar 9 2013

Project Member
Labels: -Action-BisectNeeded Needs-Bisect

Comment 12 by bugdroid1@chromium.org, Mar 11 2013

Project Member
Labels: -Area-WebKit Cr-Content

Comment 13 by bugdroid1@chromium.org, Apr 6 2013

Project Member
Labels: -Cr-Content Cr-Blink

Sign in to add a comment