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 56 users
Status: Verified
Closed: May 2012
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 1
Type: Bug

Show other hotlists

Hotlists containing this issue:

Sign in to add a comment
Chrome 19 doesn't respect basic auth details embedded in the URL
Reported by, Apr 12 2012 Back to list
Chrome Version       : 19.0.1084.15
OS Version: OS X 10.7.3
URLs (if applicable) :
Any other URL containing embedded basic auth details.
Other browsers tested: Firefox, safari
  Add OK or FAIL after other browsers where you have tested this issue:
     Safari 5: OK
  Firefox 4.x: OK
     IE 7/8/9: OK

What steps will reproduce the problem?
1. Access the URL above

What is the expected result?
That I see a page saying 'Ok'

What happens instead?
I'm prompted for a username and password

Please provide any additional information below. Attach a screenshot if

This worked before Chrome 19. I clearly understand that foo:bar is the username and password because they get a different color but for some reason it doesn't accept it.

UserAgentString: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_7_3) AppleWebKit/536.5 (KHTML, like Gecko) Chrome/19.0.1084.15 Safari/536.5

Labels: -Area-Undefined Area-Internals Internals-Network-Auth
Status: Untriaged
Labels: -OS-Mac OS-All
Status: WontFix
The support for embedded auth in URLs was intentionally deprecated.
Comment 4 by, Apr 16 2012
May I ask why? Every other browser out there supports it.

I have a lots of bookmarks with embedded auths (staging environments) and I cannot use the password manager in Chrome since I use an external tool for that.
Comment 5 by, Apr 16 2012
Its not true that every other browser supports it.  IE9 will outright reject links containing these, eg.
<a href="">click</a>, nor will it accept them typed into the location bar. 
Comment 6 by, Apr 16 2012
Well, I don't think IE is the ideal browser to have as a guideline :)

I'm just trying to comprehend your reasoning.
Could you maybe have it as an optional option?
Comment 7 by, Apr 18 2012
This is a huge pain, I use embedded credentials frequently. Can you at least allow users to enable this?
Comment 8 by Deleted ...@, Apr 19 2012
Not that IE is a guide, but I stopped relying on inline credentials a long time ago, back when I was an IE user, and they deprecated it a while back due for "security" reasons.

I did find it incredibly useful but I have not really seen anyone suggest using URLs like that anymore, I thought that IE was trailing the competition with that idea (like usual...)

Comment 9 by Deleted ...@, Apr 19 2012
URLs of this form could be used to track users in a way that cannot be managed with browser privacy options.

For example, a rogue site could link you to and then your browser would always include that uniqueid in the Authorization HTTP header sent to that server.  I believe this could even be done via an embedded hidden img tag.

Not sure if that's the rationale for the change, but it's a pretty serious problem.
Comment 10 by, Apr 19 2012
I think URL spoofing is a bigger issue

If you have this URL
The user might think they are browsing when they are in fact browsing some other site.
Though I have never seen this anyway and Chrome removes the username and password anyway so this doesn't really apply here.

However, I think a flag for enabling this would be in order.
Comment 11 by, Apr 19 2012
Another browser (which one I forget, might even have been Chrome) prompts you to confirm you want to log in with the provided credentials. This seems like a reasonable compromise. But this is frustrating enough for me that I've downgraded to Chrome 18 - I use full URL's like that constantly, and copying and pasting 3 times to log in somewhere is tedious (url, then username, then password).
Comment 12 by Deleted ...@, Apr 19 2012
the snapshot it said OK

then the chrome's version
Screenshot at 2012-04-19 13:59:06.png
9.7 KB View Download
37.5 KB View Download
Comment 13 by Deleted ...@, Apr 19 2012
and I also tried https

6.8 KB View Download
Comment 14 by Deleted ...@, Apr 19 2012
Seems like this is part of the URL standard you should support it.
If you want to protect the uninformed by defaulting it off that's fine.
But for those of us who know how to stick our hands in the fire without getting burned, please add an option to re-enable it.
Can you make the new behavior default, but allow it to be disabled through preferences or options?  It seems it would be a valid middle solution that protects novices, while still access to desired functionality for power users.
Comment 16 by Deleted ...@, Apr 19 2012
I think that you (Chromium) guys got things completely backwards.

You should add a proper UI for all HTTP authentication methods, rather than deprecate some of them.

* Prompt the user when he follows a link with basic auth if he wants to proceed, and for how long he wants the creditentials to be remembered. an hour? a day? forever? Until the browser is closed?

* Allow auth management (for all methods) in the options, next to the password manager.
Comment 17 Deleted
Basic auth as part of an HTTP URL is not part of the spec:
The use-case for this feature I've encountered most frequently is using Selenium to run automated tests against a basic-auth secured staging environment.

See for a discussion that suggests the use of auth embedded in the URL to achieve this goal.

Whilst its perfectly reasonable for the Chrome team to deprecate this unsecure and out-dated feature, some assistance in getting a better mechanism in place for running automated tests against basic-auth secured sites would be _greatly_ appreciated, as sending basic-auth credentials as part of the initial http headers is not easily achieved using WebDriver.
Comment 20 by, Apr 19 2012
"For definitive information on URL syntax and semantics, see "Uniform Resource Identifiers (URI): Generic Syntax and Semantics," RFC 2396"

See line 610ish:

Clearly, it's possible, and the inability for the password manager to remember basic auth credentials combined with removing this support from bookmarks is a significant regression in usability.

It makes sense to remove the ability for links clicked on to pass auth, but users should be able to bookmark URLs with credentials, or the password manager should work to fill in that information.
Comment 21 by, Apr 19 2012
Works for me.
Comment 22 by Deleted ...@, Apr 19 2012
SeaMonkey version 2.8 checks out okay!
Do you have a recommended log-out mechanism for basic-auth? We were using <a href="http://logout:wrongpass@domain/restricted_area">logout</a> but this no longer works.
I second comment 19 - my use case for this also in test automation, basic auth is not well supported in webdriver at the moment. Would be useful if this could be re-enabled somehow (maybe a command line switch), even if the default behaviour is not to support it.
For automated testing, you could potentially write an extension which uses the webRequest.onAuthRequired API.
Would a warning like the untrusted SSL screen be an acceptable alternative, at least for Chrome 19/20/21? This seems like a major, breaking change. (I agree with the goal, embedding creds in the URL is a Bad Idea.)
Please comply with open standards, e.g. the URL specification -- as written (with errata). Ignoring parts of the spec. is unquestionably hegemonic and counter-productive to the open source community.

If you would like to deprecate this feature, or discourage its use, please follow the Mozilla Firefox pattern and prompt the user for confirmation via chrome; (see Comment 11).
RFC 3986 updates RFC 2396, here's the section that defines this format:
If Chrome is going to disable this they need to allow 3rd party api's access to the basic auth screen so they can fill in the credentials.
Comment 30 by, Apr 19 2012
#29 If you look at #25 you can indeed fix this with an extension.
Comment 31 by Deleted ...@, Apr 19 2012
Instead of ignoring the credentials and popping up the basic auth panel, how about using them to pre-populate the basic auth panel? It might still cause issues for web drivers like selenium but at least for actual users making use of basic auth credentials in the URL it won't suddenly _break_ things.

That likely clears up #10's concern as well.
 Issue 124107  has been merged into this issue.
Comment 33 by, Apr 19 2012
Surprised to see so much usage of a feature that's been de-supported in other browsers (ie. IE) for some time.  I'd be OK with putting this behind the same command line switch as the other cross-origin auth stuff.
 Issue 124580  has been merged into this issue.
Comment 35 by, Apr 23 2012
tsepez, I'm not surprised at all. This has been part of the de-facto http:// URL format for a very long time, and it is used by a lot of tools for varying purposes. Further, it's used by people to embed credentials into personal bookmarks, among other things.

It belongs, at worst, in chrome://flags, as it should be a setting that does not require changing command-line options to enable. Further, if it's in a URL that is explicitly:

* pasted to the URL bar;
* in a bookmark; or
* supplied on the command line,

...then the user has made an explicit request to honor that URL -- so why is there any reason to disallow it at all? What use case does its deprecation address?

And speaking of "de-supported in other browsers... for some time", do you have any example besides IE? I cannot find one.
Comment 36 by, Apr 26 2012
I have filed, to get a better way to do this with webdriver.  In the meantime I had the same problem and used an extension to get around it for automation purposes.  Here is the bare-bones, good luck with it, no warranty code:

Extension code

  "name": "Basic HTTP Auth Extension",
  "version": "1.0",
  "description": "Send credentials to basic HTTP auth pages.",
  "browser_action": {
    "default_icon": "icon.png"

  "background": {
    "scripts": ["background.js"]

  "permissions": [

// background.js

var gPendingCallbacks = [];
var bkg = chrome.extension.getBackgroundPage();

  {urls: ["<all_urls>"]}, ["asyncBlocking"]);

function processPendingCallbacks() {
  bkg.console.log("Calling back with credentials");
  var callback = gPendingCallbacks.pop();
  callback({authCredentials: {username: <your username>,
                              password: <your password>}});

function handleAuthRequest(details, callback) {

Python code that loads the extension:
  extension_path = <path to extension>
  f = open(extension_path, 'rb')
  base64_extensions = []
  base64_ext = (binascii.b2a_base64(
  self.driver = webdriver.Remote('', {'chrome.extensions': base64_extensions})

Now when I do driver.get('url to http auth site'), it logs right in and take me to the page.
Comment 37 by Deleted ...@, Apr 26 2012
That is the problem with Chrome.  They think they can just decide to make breaking changes and roll them into your next update whenever they feel like it without checking with anyone.

Chrome fanboys are idiots.  Google does not know best, and yes they are becoming evil.
Comment 38 by, Apr 26 2012
I love that you commented from a gmail address
Comment 39 by Deleted ...@, May 7 2012
just wondering, does this also break basic auth for cross origin xmlhttprequests made from within extensions, like this:"post", "someurl", false, "myuser", "mypass");

in chrome 18 this works, in chrome 19 there's no such luck. conversely, manually setting authorization header for the xhr works in 19, but not in 18.
I am having the issue in #39, but not in an extension, just on a normal web page., username, password) just doesn't send any auth headers.  This code worked in Chrome 18, but breaks in Chrome 19.
Comment 41 by Deleted ...@, May 17 2012
#36, you posted a workaround that works like a charm! Thanks a ton! :)

Here's a step-by-step for those using ruby and watir-webdriver:

1. Pack the extension that #36 provided. Use this guide, if not sure how this is done:

The result is a '*.crx' file that will be loaded into Chrome.

2. Ruby/watir-webdriver code to load the extension into a remote driver:

chrome_extensions = []
        chrome_auth_extension_path = <path to the *.crx file>
, "rb") do |file|
            chrome_extensions << Base64.encode64(
        rescue Exception => e
          raise "ERROR: Couldn't or Base64.encode64 a Chrome extension: #{e.message}"

        # Append the extensions to your capabilities hash
        my_capabilities.merge!({'chrome.extensions' => chrome_extensions})
        desired_capabilities =

        browser =, :url => 'http://localhost:4444/wd/hub', :desired_capabilities => desired_capabilities)

As someone that is just learning Ruby and the Webdriver API, I hope this helps other newbies. :)
Could we please have a setting for this?  Even IE9 allows you to overcome the issue through a registry setting.  Come on people, let's not break standard specs.
I started using URLs with embedded credentials when Chrome started ignoring auth requests for embedded objects (particularly images).

I have a bunch of IP cameras, each of which has its own web server. To view all of them at once, I have a web page that simply has an img for each camera. The cameras use HTTP basic auth, and this used to pop up an authorization dialog for each camera, but then a while back Chrome stopped showing these dialogs "for security reasons".

To work around this I added the credentials to the src URLs. (The page that contains these images is just as secure as the cameras themselves, so this isn't a real security problem.) Unfortunately, today I noticed that my workaround that was created specifically for Chrome is now ignored by Chrome.
Comment 44 by Deleted ...@, May 21 2012
Please, back this function!

I understand about security risks, but i need it like every day!
Just make this function disabled by default and checkbox to enable this function in menu.

Comment 45 by Deleted ...@, May 21 2012
Maybe it's possible to add it for specific domains which may be configurable.
@#39: "in chrome 18 this works, in chrome 19 there's no such luck. conversely, manually setting authorization header for the xhr works in 19, but not in 18."

I found than manually setting authorisation header for xhr works fine in 18 and 19. Are you sure you are doing it right?
For anyone using xhr this workaround should be fine. No need to do the solution in #36.

old way:"POST", url, true, http_basic_username, http_basic_password) ;

New way:"POST", url, true);
    var auth_header = "Basic " + Base64.encode(http_basic_username + ":" + http_basic_password) ;
    xmlhttp.setRequestHeader("Authorization", auth_header) ;

In my opinion this decision is a lack of formality, how can be a feature disabled this way? that is hilarious, is like you remove a method from a library but with the difference that the final users have to change always to the last version. This is not nice... So now I have to change all the sites where I'm using basic auth? Come on...
Please, at least, leave the choice to the users, let them decide if they want to activate it...
Agreed. Notwithstanding that a browser is meant to "ahdere to the standard".  
Comment 49 by, May 21 2012
#46  Two potential problems with your solution. Firstly, that works with basic authentication but not digest authentication whereas open() method used to work with both basic and digest.

Secondly, using setRequestHeader means the browser doesn't store your login credentials. I use xmlhttprequest to login to my website and then redirect the browser into the site. The browser would then remember the credentials and send them to the server for each request. If you set the Authorization header, you have to continue to set it for every request and the browser cant be sent to a secure page.
#49 yes you're right about that. In my particular implementation neither are issues as I use Basic Auth + get an implementation-specific authentication token after the initial request.
Comment 51 by Deleted ...@, May 21 2012
Would like to second all the folks here!

Disabling a feature used over decades for security reasons - sure you have reasons for.
Not giving any ***simple*** way of falling back to the standard behavior - inexcusable. (Because in this case it would be easily possible to do so!)

You just broke thousands of test automation systems word-wide ;)
Labels: -Pri-2 Pri-1 Mstone-19
Status: Untriaged
Comment 53 Deleted
tsepez: In Chrome19, embedded auth is intentionally disabled. There is no option to disable it, which is also intended.  Is the XHR-related behavior change intentional, or was this an unintended regression?
Comment 55 by Deleted ...@, May 21 2012
i made an extension for chrome to solve this issue temprorary. maybe it'll help somebody.
quick and not perfect solution... but it works)
 Issue 128323  has been merged into this issue.
Comment 57 by, May 21 2012
Why am I cc'd?
not sure, removed you
Comment 59 Deleted
This is brilliant. Added the extension to ChromeDriver and works like a charm. Thanks!
Comment 61 by Deleted ...@, May 22 2012
The extension works fine
Thanks for your hard work
I'm having the same problem as #49.

Simple question: How can I make Digest authentication work with XHR on Chrome 19? The credentials provided in the open()-function is ignored and Chrome asks the user instead.

Setting the header won't work. since the nounce is not known before trying to access the resource.

Comment 63 by Deleted ...@, May 22 2012
@62 try the extension above. 
Tested it on the following code.. works correct.

function getXmlHttp(){
  var xmlhttp;
  try {
    xmlhttp = new ActiveXObject("Msxml2.XMLHTTP");
  } catch (e) {
    try {
      xmlhttp = new ActiveXObject("Microsoft.XMLHTTP");
    } catch (E) {
      xmlhttp = false;
  if (!xmlhttp && typeof XMLHttpRequest!='undefined') {
    xmlhttp = new XMLHttpRequest();
  return xmlhttp;

var xmlhttp = getXmlHttp()'GET', 'http://admin:password@*******.com:8080/', false);
if(xmlhttp.status == 200) {
yes your extension probably work but we need normal Digest authentication through XHR to work out of the box, without any extensions.

The authentication is used on a live production system and this is not for testing.

Project Member Comment 65 by, May 22 2012
The following revision refers to this bug:

r138264 | | Tue May 22 09:08:16 PDT 2012

Changed paths:

Re-enable embedded identities in URLs for HTTP authentication.

This effectively reverts r121506.

BUG= 123150 
TEST=net_unittests. Username/passwords specified in URLs work. XmlHttpRequests() with credentials passed as arguments work.

Review URL:
Labels: Merge-Requested
Status: Started
Anthony - we'd like to merge something like r138264 into M19. Only need the change to for now. The test changes will require some manual work.
Comment 67 by, May 22 2012
Labels: -Merge-Requested Merge-Approved
@asanka: do we really want to wholesale revert r121506? It sounds like we need to just unbreak"POST", url, true, http_basic_username, http_basic_password) ;

@scarybeasts: asanka, tsepez, and I had a long conversation about supporting that case yesterday. Unfortunately, not easy since WebKit will generate a URL with embedded username/password in that case, and no way to differentiate that at the point it's being killed in the HttpAuthController and browser process. We all agreed this is appropriate for now followed by other changes to make that case work but not allow the embedded credentials case. Also need better test coverage for this case.
Where and when exactly was this change made? In Chrome 19 or in a certain WebKit version? If the later, will future Safari versions with the same WebKit behave the same?
Oh, wait, I just saw the last comment. Does this mean Chrome will support URL auth details in the next release again? So it only does not work in Chrome 19?
I would just like to add another voice about losing embedded auth functionality.
I use Google Chrome in full screen mode as a public information system and one of the things it does is display our network cameras on the screen - the network cameras images are accessed like this: http://username:password@ while Firefox would pop up a box asking if I want to log in to site using the supplied credentials - it would quite happily load the image if the credentials are used in an image tag. Chrome used to support this functionality too - but now all the pages on the presentation that should load Network Camera feeds instead load a page that says "401 - Unauthorized" attempting to paste the URL directly into the address bar pops up a login box with no username or password pre-filled. I really don't want to have to go to the length of writing a proxy in PHP - but I suppose I will have to depending on what your plans are for supporting or not this use case.
@36, I have tried using the extension but it does not seem to work for me. First I got a syntax error on the JSON file when packing it so I terminated the strings "http://*/*..."  with a ",

This allowed me to pack and install the extension but I still get authentication messages.  Is there anything obviously wrong for a Chrome extension newbie?
Status: Fixed
This should be resolved in the current stable release.
Comment 76 by, May 24 2012
Can you please confirm what you mean by fixed? Because basic auth credentials in URLs still doesn't work in 20.0.1132.11 beta (I'm assuming that if it's fixed in stable it's fixed in beta at least)
Labels: -Mstone-19 -Merge-Approved Mstone-20 Merge-Requested
Status: Started
Comment 78 by, May 24 2012
Labels: -Merge-Requested Merge-Approved
Project Member Comment 79 by, May 24 2012
Labels: merge-merged-1132
The following revision refers to this bug:

r138890 | | Thu May 24 14:18:45 PDT 2012

Changed paths:

Merge 138264 - Re-enable embedded identities in URLs for HTTP authentication.

This effectively reverts r121506.

BUG= 123150 
TEST=net_unittests. Username/passwords specified in URLs work. XmlHttpRequests() with credentials passed as arguments work.

Review URL:
Project Member Comment 80 by, May 24 2012
The following revision refers to this bug:

r138905 | | Thu May 24 14:57:39 PDT 2012

Changed paths:

Revert 138890 - Merge 138264 - Re-enable embedded identities in URLs for HTTP authentication.

This effectively reverts r121506.

BUG= 123150 
TEST=net_unittests. Username/passwords specified in URLs work. XmlHttpRequests() with credentials passed as arguments work.

Review URL:
Review URL:
Project Member Comment 81 by, May 25 2012
The following revision refers to this bug:

r138992 | | Thu May 24 21:42:10 PDT 2012

Changed paths:

Merge 138264 - Re-enable embedded identities in URLs for HTTP authentication. (Second attempt)

This effectively reverts r121506.

BUG= 123150 
TEST=net_unittests. Username/passwords specified in URLs work. XmlHttpRequests() with credentials passed as arguments work.

Review URL:
Review URL:
Status: Fixed
Merged to M20 branch as well.

Status: Verified
 Issue 128902  has been merged into this issue.
Comment 85 by, Aug 8 2012
Labels: -Merge-Approved
Remove merge approval label, this release has passed.
Comment 86 by, Aug 8 2012
Remove merge approval label, this release has passed.
Comment 87 by, Aug 8 2012
Remove merge approval label, this release has passed.
Was this included in the iOS version as well?  Are there plans to remove it from the iOS version as well (since it seems to be there as well)>?
Project Member Comment 89 by, Mar 10 2013
Labels: -Area-Internals -Internals-Network-Auth -Mstone-20 Cr-Internals-Network-Auth M-20 Cr-Internals
Comment 90 by Deleted ...@, Apr 8 2013
Can this be included in the iOS version of Chrome? Still doesn't work there :(
Could it be possible to know what's the current state of this issue ?
Comment 92 by, Apr 3 2014
This bug, as written, no longer applies (HTTP basic auth credentials in URLs work again), at least up through Chrome 34.
Hm, I haven't been able to do :

    var x = new XmlHttpRequest( ); 'GET', '', true );
    x.send( null );

(unable as in, the credentials weren't passed to the remote server)

I'm not sure if it matches this issue, tho, especially with the XHR2 withCredential property.

Comment 94 by Deleted ...@, May 7 2014
Hi ChromeDev team, I am on 34.0.1847.131. Looks like this bug has resurfaced? (No more Auth header sent with credential in URL)
#94: Could you open a new issue?
It works for me with 35.0.1916.114.

However, the credentials are getting discarded in case of a redirect.

E.g. If I open and there's a redirect to https:// version of this site, the credentials are not making their way to .

Yes. Credentials used with HTTP authentication aren't transitive across a redirect. They can only be used to respond to authentication challenges coming from the server in the URL.
This issue appears to be back with Canary 59...
Comment 99 by, Mar 30 2017 is tracking the recent work.
Credentials should be transitive across a redirect to the same protocol and host, correct?

If the credentials in the URL were used to respond to an authentication challenge successfully (and a redirect counts as a success), then those credentials can be cached and reused with a request to the same origin. Due to that mechanism, it may give the appearance of the credentials being transitive.

I'm confused. Reused cached credentials is not considered transitive? What is "transitive" then, for basic auth?
I guess it depends on what you mean by "transitive". The spec does not require and indeed it would be incorrect for credentials embedded in one URL would be applied to another only on the basis of the first URL redirecting to the other. Embedded credentials are only applicable to the URL in which it was embedded.

However, the spec allows a UA to reuse previously used credentials, pre-emptively or otherwise, when requesting another URL that falls within the same protection space. This allowance is what I was referring to in #101. It has nothing to do with credentials being "transitive across a redirect."

I still don't understand what "transitive" refers to. Let's try an example where:

which redirects to
will *not* produce a redirected URL of


with links to 
will both *not* produce a link URL of

...however, both situations will use the originally embedded credentials as authorization headers to preserve realm access. To me this is transitive.
Comment 105 by, Jun 13 2017
Am I way off base?
Sign in to add a comment