597301 - CORS: Cross-domain PROPFIND XHR request for servers with Basic authentication does not work.

Status: RESOLVED FIXED

(Core :: DOM: Core & HTML, defect)

Description

[Vladimir Lichman]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US) AppleWebKit/534.3 (KHTML, like Gecko) Chrome/6.0.472.59 Safari/534.3
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.10) Gecko/20100914 Firefox/3.6.10 (.NET CLR 3.5.30729) 

When you submit cross-domain PROPFIND request using XmlHttpRequest to a server that is using Basic authentication the request silently fails. No login dialog is displayed.

The same issue if the server is using Integrated Windows Authentication. For servers with Digest or anonymous authentication the request works with no problem. Cross-domain GET and POST requests work fine. 


Reproducible: Always

Steps to Reproduce:
1. Go to http://www.ajaxfilebrowser.com/?CrossDomainDemo
2. Enter url of the WebDAV server that is using Basic authentication in 'WebDAV Server Url' field. For example this one: http://www.ithit.com:8044/
 Login: User1
 Password: pwd
3. Click "Connect" button.

Using a debugging proxy you can find that preflight OPTIONS request is being sent but no login dialog is displayed and no PROPFIND request is sent. 
Actual Results:  
No login dialog displayed, request failed.

Expected Results:  
Login dialog is displayed. PROPFIND is submitted to server. 

Chrome browser work with Basic, Digest and Integrated windows with no problem.

Comment 1

[Boris Zbarsky [:bzbarsky]]

So in this case the server responds to the OPTIONS request with a 401, right?

The CORS spec recently changed how 4xx response codes need to be handled; this is a duplicate of the bug on us making that change to our code...

Comment 2

[Anne (:annevk)]

Actually, for preflight requests we agreed that no credentials are to be included in the request. So this would be a bug in Chrome, I think.

Comment 3

[Boris Zbarsky [:bzbarsky]]

The preflight doesn't include credentials.  But then the server responds with a 401, is the intent not to include credentials for the 401 at that point?  The spec goes out of its way now to say that 4xx errors are not immediately fatal...

Comment 4

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Actually, wouldn't it make the most sense to say that the OPTIONS response has to be a 2xx/1xx response? It seems very strange to just treat a 200 and a 404 response from the OPTIONS request completely identical.

Comment 5

[Anne (:annevk)]

Prolly. Email the list?

Comment 6

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Attachment: WIP

This should work but needs tests. Attaching so I don't loose it.

Note that I think the spec should require a 2xx response to OPTIONS requests, and have implemented this strategy. I also raised the issue on the list.

Comment 7

[Julian Reschke]

(In reply to comment #6)
> Created attachment 477373 [details] [diff] [review]
> WIP
> 
> This should work but needs tests. Attaching so I don't loose it.
> 
> Note that I think the spec should require a 2xx response to OPTIONS requests,
> and have implemented this strategy. I also raised the issue on the list.

Why require a 2xx for OPTIONS when other methods require authentication? I think it's totally plausible that the server responds with 401 to *all* unauthenticated requests (actually, authentication checks may happen before even looking at the method).

Comment 8

[Julian Reschke]

Also, out of curiosity: why is there a preflight request for PROPFIND anyway?

CORS, 6.1.5.:

"To protect resources against cross-origin access with methods that have side effects an preflight request is made to ensure that the resource is ok with the request."

RFC 4918, 9.1.:

"...This method is both safe and idempotent (see Section 9.1 of [RFC2616])..."

Comment 9

[Boris Zbarsky [:bzbarsky]]

> Also, out of curiosity: why is there a preflight request for PROPFIND anyway?

Because CORS says to do so.

> CORS, 6.1.5.:

The text you're quoting is informative.  The normative text is that if there is no method cache match for the method and the method is not a simple method you have to preflight.  In this case, there is no preflight result cache entry (and in fact I don't think we have a preflight cache) and the definition of "simple method" in CORS is:

  A method is said to be a simple method if it is a case-sensitive match for
  one of the following:
    GET
    HEAD
    POST 

In other words, it seems that what CORS really uses preflights for is "check before doing anything weird", not what it claims at the top of 6.1.5.

Comment 10

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Please stick to one issue per bug.

And spec discussions are better held on the Webapps mailing list. No decisions can or will be made here regarding changing the spec.

Comment 11

[Vladimir Lichman]

I agree that all requests including OPTIONS request must be authenticated. In case OPTIONS requests are unauthenticated (so the server never replies with 4xx code) it will have following disadvantages:

1. Changes to server code will be required. In many cases we can add headers required by CORS, but not to change the code on server side.

2. If OPTIONS request is unauthenticated this probably is a security risk. The user can use it to test folders existence.

Comment 12

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Attachment: Patch to fix

This updates us to spec for a range of smaller issues:

* Don't make requests fail for http-errors. I.e. 404 responses are still forwarded. Note that http-errors in the preflight response still results in a failed request (this also allowed me to remove some media-element code which whitelisted some error codes)

* If a HEAD request is preflighted, don't require access-control-allow-methods to include 'head'

* Remove special handling for "Content-Type" header on POST requests. Instead simply treat "content-type" as a preflighted header if it doesn't have one of the white-listed values.

* Change tests to make it easier to check that both failing conditions and succeeding conditions for the same feature are tested. I.e. rather than having all denying tests listed together, and all succeeding tests listed together, annotate on each test if it's expected to be denying or succeeding, and reorder them.

Comment 13

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Attachment: Add support for access-control-expose-headers

The CORS spec has changed in one more way, it has grown a new feature. It is now possible for the server to whitelist headers which the requesting site can access using the usual XMLHttpRequest.getResponseHeader. Previously only a small whitelist of headers could be read using this API, now additional headers can be whitelisted by the server using the "access-control-expose-headers" response header.

Comment 15

[Vladimir Lichman]

There is a discussion about similar CORS issue in  Safari/WebKit: https://bugs.webkit.org/show_bug.cgi?id=45943

Comment 16

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Eeep, forgot to pull this in to beta7 before checking in.

Since it's changing some behavior towards web pages I figured it was better than not to land this for beta7.

http://hg.mozilla.org/mozilla-central/rev/a5b5aeb0b4f0
http://hg.mozilla.org/mozilla-central/rev/9df5d817b35b

Comment 17

[Vladimir Lichman]

I assume beta7 is the Firefox version 3.7? Are there any information when it will be released?

Comment 18

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Beta 7 is Firefox 4 beta 7. It'll likely be released in a matter of a week or two. This is not the place to ask though, the mozilla.dev.planning newsgroup is a better place.

Comment 19

[Eric Shepherd [:sheppy]]

Looking through this it appears that the addition of "Access-Control-Expose-Header" is the thing that needs documenting here; everything else appears to just be bug fixes. Is that forrect?

I've documented access-control-expose-header here:

https://developer.mozilla.org/En/HTTP_access_control#Access-Control-Expose-Header

Please have a look and let me know if that's correct.

Comment 20

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

We should also mention that "text/plain", "application/x-www-form-urlencoded" and "multipart/form-data" encoded data can be sent cross-site without requiring a preflight. (The last is particularly useful together with FormData).

Previously only "text/plain" was allowed to be sent cross site without preflight.

Comment 21

[Eric Shepherd [:sheppy]]

Added a note about the encodings here:

https://developer.mozilla.org/En/HTTP_access_control#Preflighted_requests