Hi All, I'm attempting to understand some (thankfully consistent) behavior that I am seeing across browsers that, to my interpretation, does not follow the XMLHttpRequest specification (Level 2 Working Draft). Hopefully you can provide some guidance or point me in the appropriate direction.
Near the end of Section 4.7.6 The send() method is the following: If the user agent supports HTTP Authentication and Authorization is not in the list of author request headers, it should consider requests originating from the XMLHttpRequest object to be part of the protection space that includes the accessed URIs and send Authorization headers and handle 401 Unauthorized requests appropriately. 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. [HTTPAUTH] End users are not prompted for various cases so that authors can implement their own user interface. In my same-origin scenario, I would like to reach the last statement so that I am able to "implement my own user interface". It seems that the only way to NOT have the browsers automatically "handle 401 Unauthorized requests appropriately" is to provide an Authorization header in the list of author request headers. This would force the behavior that the browser would not prompt the end user. However, I would need to send an empty Authorization header or some sort of username and password initially - even if it is not required by the server. There is also the situation where I would send an invalid username/password merely so that the header is set - similar to the discussion from a few years ago regarding Digest authentication [1] (this thread seems to cover what I'm asking here but is specific to Digest authentication). While I do understand some of the desire to handle 401 requests transparently, I have a use-case where the 401 "failure" should be handled NOT by the browser, but instead by script to capture the appropriate type of credentials from the user instead of presuming that username and password for Basic Authentication is required. The XMLHttpRequest specification seems to accommodate this scenario, but getting the browser into the appropriate state seems to be a bit of a challenge. Is my interpretation of the XMLHttpRequest specification flawed, is there a need for the browser behavior to change, or is my requirement just not serious enough? There are many use-cases where a non-browser interface or interaction is highly desirable for authentication, particularly when using XMLHttpRequest. If additional use-cases would help explain my question then I'd be happy to provide them. Additionally, I can think of use-cases where not prompting the user may lead to undesirable consequences, such as a password guessing attack. However, I think the existing work already performed to not allow Authorization headers across orgins mitigates the exposure to distributed password guessing. Kind Regards, Tim Hobbs [1] http://lists.w3.org/Archives/Public/public-webapps/2010JulSep/0319.html
