629658 - Unable to perform XMLHttpRequest CORS request with credentials: NS_ERROR_DOM_BAD_URI

Status: RESOLVED INVALID

(Firefox :: General, defect)

Description

[Mathias Brodala]

User-Agent:       Mozilla/5.0 (Windows NT 6.1; rv:2.0b11pre) Gecko/20110127 Firefox/4.0b11pre
Build Identifier: Mozilla/5.0 (Windows NT 6.1; rv:2.0b11pre) Gecko/20110127 Firefox/4.0b11pre

Trying to perform a CORS request with XMLHttpRequest Level 2 fails no matter what I try. I am providing the username and password as parameters to the open() method of the XMLHttpRequest object assuming that this causes the Authorization HTTP header to be set.

I am setting the withCredentials property of the XMLHttpRequest object to true to signify the usage of credentials via CORS requests.

However, this only yields an obscure NS_ERROR_DOM_BAD_URI error which is related to internal redirects as I can take from the source. A real HTTP request is never performed.

Not providing the username and password via the open() method results in Firefox prompting for these with an authorization dialog.

Manually generating the Authorization HTTP header and passing it via the setRequestHeader() method only yields an unknown error (the onerror handler of the XMLHttpRequest object is invoked) which is impossible to identify due to it being a mere ProgressEvent error.

See the test case attached to this report to verify the issue and let me know what I have to do to make this work if there is anything I can do.

Reproducible: Always

Steps to Reproduce:
1. Perform a XMLHttpRequest CORS request with credentials provided and the withCredentials property enabled
Actual Results:  
The request is aborted with a NS_ERROR_DOM_BAD_URI error.

Expected Results:  
The request is performed thanks to the provided credentials and the response returned.

Comment 1

[Mathias Brodala]

Attachment: Test case performing XMLHttpRequest CORS requests with credentials

Comment 2

[Mathias Brodala]

Attachment: Server side script accepting CORS requests from any origin

Comment 3

[Bjarne (:bjarne)]

Do you load your page/script from a file? That doesn't work in FF, but I've seen it working in IE8 and Safari. See bug #634906.

Moreover, please note that if you do a CORS call with credentials, the "*" response is not sufficient - it must match literally the value of the Origin request-header (see steps 2 and 3 in section 6.2 in the W3C CORS spec).

Comment 4

[Mathias Brodala]

(In reply to comment #3)
> Do you load your page/script from a file? That doesn't work in FF, but I've
> seen it working in IE8 and Safari. See bug #634906.

No, regular access via HTTP.

> Moreover, please note that if you do a CORS call with credentials, the "*"
> response is not sufficient - it must match literally the value of the Origin
> request-header (see steps 2 and 3 in section 6.2 in the W3C CORS spec).

Yes, I read that; the "*" in my example was only for presentation purposes. The real script explicitly sends the name of the allowed origin. (OK, I could have set "https://bugzilla.mozilla.org" for this example, not sure if SSL vs. non-SSL would have caused another issue here though.)

Comment 5

[Bjarne (:bjarne)]

An initial observation is that your test-server actually do respond with "*" as the allowed origin. This *will not work* when setting withCredentials (see the CORS spec as mentioned in comment #3). I'd suggest that you modify your test-server to pick up whatever origin is requested and return that string (obviously, this should not be done for the real server).

Comment 6

[Mathias Brodala]

(In reply to comment #5)
> An initial observation is that your test-server actually do respond with "*" as
> the allowed origin. This *will not work* when setting withCredentials (see the
> CORS spec as mentioned in comment #3). I'd suggest that you modify your
> test-server to pick up whatever origin is requested and return that string
> (obviously, this should not be done for the real server).

I now changed it to respond with "http://" + REMOTE_ADDR. However, the issue is that Firefox never even goes that far. As written in the original report, no HTTP request is ever performed, at least none visible to me. Thus from my POV Firefox never reaches the state where it can actually evaluate the response headers.

Comment 7

[Bjarne (:bjarne)]

(In reply to comment #6)
> I now changed it to respond with "http://" + REMOTE_ADDR. 

I'd rather suggest you respond with whatever origin the client requests. If you look into the W3C CORS spec, you'll see why.

> However, the issue is
> that Firefox never even goes that far. 

You might be seeing bug #580353.

A few questions to satisfy my curiosity: Does this work in FF 3.6? And how do you track what FF does?

Comment 8

[Boris Zbarsky [:bzbarsky]]

So... maybe I'm missing something, but http://www.w3.org/TR/XMLHttpRequest2/#the-open-method steps 13 and 14 seem to say that explicit user/password arguments passed to open() for a cross-origin request should throw.  That's what we do.

What confuses me is that the same spec seems to say that a username:password in the URI itself should be honored.  Is that actually the case?  The difference seems ... odd.

Comment 9

[Mathias Brodala]

(In reply to comment #8)
> So... maybe I'm missing something, but
> http://www.w3.org/TR/XMLHttpRequest2/#the-open-method steps 13 and 14 seem to
> say that explicit user/password arguments passed to open() for a cross-origin
> request should throw.  That's what we do.

You are absolutely right, not sure how I could miss this. It is even mentioned in the info box. I was under the assumption that XHR2 would also allow for this.

I can kind of understand the reasoning behind this as mentioned in https://bugzilla.mozilla.org/show_bug.cgi?id=580353#c1

> What confuses me is that the same spec seems to say that a username:password in
> the URI itself should be honored.  Is that actually the case?  The difference
> seems ... odd.

That’s what I could try aside from dropping HTTP authentication altogether. And yes, from the security POV, there is no difference.

Comment 10

[Mathias Brodala]

(In reply to comment #7)
> > However, the issue is
> > that Firefox never even goes that far. 
> 
> You might be seeing bug #580353.

Thanks for this hint.

> A few questions to satisfy my curiosity: Does this work in FF 3.6?

No, same error.

> And how do you track what FF does?

Web Console and LiveHTTPHeaders.

Comment 11

[Boris Zbarsky [:bzbarsky]]

> And yes, from the security POV, there is no difference.

Right.  Which confuses me, since the ostensible goal here is security....

Comment 12

[benson margulies]

Hi, I've hit this issue using plain XMLHttpRequest, not '2'. Is it also speced to explode on contact with credentials?

Comment 13

[benson margulies]

I also can't get it to work with credentials in the URL. Is the only use of the allow-credentials thing cookies?

Comment 14

[Boris Zbarsky [:bzbarsky]]

> Hi, I've hit this issue using plain XMLHttpRequest, not '2'

There is no such thing.  There is only '2' as you put it.

> Is the only use of the allow-credentials thing cookies?

No.  It includes HTTP auth and user certs.

Comment 15

[Anne (:annevk)]

Credentials in the URL itself is actually an open issue in general.

https://www.w3.org/Bugs/Public/show_bug.cgi?id=10326