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 6 users

Issue metadata

Status: Duplicate
Merged: issue 123150
Owner: ----
Closed: May 2012
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 2
Type: Bug

  • Only users with Commit permission may comment.

Sign in to add a comment

Issue 128323: w/ username/password returns 401 in Chrome 19 (worked in 18)

Reported by, May 16 2012

Issue description

Chrome Version       : 19.0.1084.46
OS Version: 6.1 (Windows 7, Windows Server 2008 R2)
URLs (if applicable) :
Other browsers tested:
Add OK or FAIL after other browsers where you have tested this issue:
     Safari 5: n/a
  Firefox 4.x: n/a
     IE 7/8/9: n/a

What steps will reproduce the problem?
1. Get a Delicious account ( or use an existing one.
2. Install extension:
3. Try to log in with the Delicious account username and password.
4. It will say "Error: Unknown username or password. Please try to login again."
5. Inspecting the popup shows the 401 error.

What is the expected result?

  The extension is using XMLHttpRequest like this:"GET", "", true, userName, password);

  This translates to this:

  This should authenticate the GET request, and XML should be returned with the response from the API call.

  This worked in Chrome 18, and in previous versions stretching back over a year.

What happens instead?

  Delicious returns a "401 Unauthorized", and this XML: <?xml version="1.0" encoding="UTF-8"?><result code="access denied"/>

  It is as if Chrome is not actually sending the username/password at all anymore.

Please provide any additional information below. Attach a screenshot if

  The same issue is happening for the Pinboard API.

UserAgentString: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/536.5 (KHTML, like Gecko) Chrome/19.0.1084.46 Safari/536.5

Comment 1 by, May 16 2012

This also applies to XMLHTTPRequests issued from files loaded from file:/// while in --disable-web-security mode.

Same behavior as above where the first request is given a 401 and no followup is sent.  Previously a 401 would occur and would be immediately followed-up by another request with the specified credentials.

Comment 2 by, May 17 2012

Labels: -Area-Undefined Area-Internals Feature-Extensions
Status: Available
This might be caused by content security policy. I'm not entirely sure how that works.

Comment 3 by, May 18 2012

Labels: -OS-Windows OS-All Internals-Network-Auth
Summary: w/ username/password returns 401 in Chrome 19 (worked in 18)
Specifying the username/password in results in a URLRequest that has an embedded identity.

E.g.:"GET", "", "user", "pass");
   ...will result in a request for "

Chrome 19 dropped support for URL embedded identities (since So the credentials in the URL aren't used to respond to the 401 challenge.

Comment 4 by, May 19 2012

Solution: I changed code to do basically this:

I went with the jQuery / $.ajax option.

Comment 5 by, May 21 2012

Mergedinto: 123150
Status: Duplicate

Comment 6 by, 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 7 by, Mar 10 2013

Project Member
Labels: -Area-Internals -Feature-Extensions -Internals-Network-Auth Cr-Platform-Extensions Cr-Internals-Network-Auth Cr-Internals

Sign in to add a comment