When you submit cross-domain PROPFIND request in Safari using XmlHttpRequest to a server that is using Basic, Digest or Windows authentication the request silently fails. No login dialog is displayed. For servers with anonymous authentication the request works with no problem. Steps to Reproduce: 1. Go to http://www.ajaxfilebrowser.com/?CrossDomainDemo 2. Enter url of the WebDAV server that is using authentication in 'WebDAV Server Url' field. For example this one that is using Basic: 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. Chrome browser work with Basic, Digest and Integrated windows with no problem.
This sounds like a serious issue in Chrome loading code, CC'ing Darin Fisher. Users are never supposed to get an authentication dialog for a cross origin XHR - if they did, that would be an extremely confusing UI. So, the spec forbids it, and the users should be already logged in to the remote site in order for authenticated cross origin requests to work. And even then, the requests only work if "withCredentials" attribute is set on XMLHttpRequest object. Closing as INVALID, since this is not a bug as reported, but this should be filed in Chrome bug tracker.
Thank you for explanation Alexey. Does this mean that before sending PROPFIND to server with Basic auth we have to send GET request somehow (for example include a hidden iframe on a page)? The GET request will trigger the login dialog, and after that we can send PROPFIND with withCredentials=true ? By the way cross-origin XHR request for PROPFIND works in Firefox with Digest auth. But OPTIONS are allowed to be unauthenticated on our Digest test server.
This doesn't depend on the method. Here is what XMLHttpRequest 2 draft spec says: ------------- If authentication fails, XMLHttpRequest origin and the request URL are same origin, Authorization is not in the list of author request headers, request username is null, and request password is null, user agents should prompt the end user for their username and password. Otherwise, if authentication fails, user agents must not prompt the end user for their username and password. ------------- Note that for requests that are not same origin, we must not prompt the user. > Does this mean that before sending PROPFIND to server with Basic auth we have to send GET request somehow (for example include a hidden iframe on a page)? This may work, but it really shouldn't - it makes no sense to display an authorization dialog for a site other than the one the user has navigated to. If this works, perhaps we should prevent it in the future. A much better UI would be to let the user know what they doing by prominently displaying the other site's UI for authentication. > By the way cross-origin XHR request for PROPFIND works in Firefox with Digest auth. If Firefox asks for credentials when making cross origin XMLHttpRequests, then it's a Firefox bug.
Alexey, what we are trying to implement a Ajax interface for WebDAV server. WebDAV server does not have any user interface and no UI for authentication as well. Most WebDAV servers use Basic, Digest or Integrated Windows authentication. What would be the correct approach in this case? Our customers request a cross domain support as it is inconvenient for them (and often not possible) to deploy JavaScript files, HTML pages and images to existing WebDAV server. It looks like this is the only blocking issue left. (In reply to comment #3) > This doesn't depend on the method. Here is what XMLHttpRequest 2 draft spec says: > > ------------- > If authentication fails, XMLHttpRequest origin and the request URL are same origin, Authorization is not in the list of author request headers, request username is null, and request password is null, user agents should prompt the end user for their username and password. > > Otherwise, if authentication fails, user agents must not prompt the end user for their username and password. > ------------- > > Note that for requests that are not same origin, we must not prompt the user. > > > Does this mean that before sending PROPFIND to server with Basic auth we have to send GET request somehow (for example include a hidden iframe on a page)? > > This may work, but it really shouldn't - it makes no sense to display an authorization dialog for a site other than the one the user has navigated to. If this works, perhaps we should prevent it in the future. > > A much better UI would be to let the user know what they doing by prominently displaying the other site's UI for authentication. > > > By the way cross-origin XHR request for PROPFIND works in Firefox with Digest auth. > > If Firefox asks for credentials when making cross origin XMLHttpRequests, then it's a Firefox bug.
You can generate and set the Authorization header yourself. It will not be included in the preflight request, but will be part of the actual request. The preflight request is just a server capability check, to see whether it understands CORS at all, so does not need to be authenticated.
> You can generate and set the Authorization header yourself. Will it work for cross origin requests? That would enable distributed password search, wouldn't it?
The resource has to opt in to allowing that header in cross-origin requests.
As far as I understand, the CORS spec requires the server to handle OPTIONS without authentication. That's a serious problem for protocols that already use OPTIONS, and require authentication. In many frameworks, authentication happens before the request (headers + body) can be expected, so this will be very hard to deploy.
Unless I'm missing something, the OPTIONS issue is tangentially related to this at best. Either way, cross origin XMLHttpRequest isn't going to show an authentication dialog.