From http://www.w3.org/TR/XMLHttpRequest/: -- If authentication fails, and request username and request password are both null, user agents SHOULD prompt the end user for credentials. If authentication fails, and request username and request password are provided, user agents MUST NOT prompt the end user for credentials. [RFC2617] Note: End users are not prompted if credentials are provided through the open() API so that authors can implement their own user interface. -- Currently, Safari always prompts for credentials (both the desktop version and MobileSafari). On the iPhone when used from UIWebView the situation is even worse: a login prompt is not shown and the readystatechange event doesn't occur... the connection just stalls. Radar bug #7497786 Same bug in Firefox: https://bugzilla.mozilla.org/show_bug.cgi?id=282547
I thought we had a bug tracking this, but cannot find it now.
This bug is still around and is causing me trouble. I'll provide some specifics and a live test case. Check out https://mail.google.com/mail/feed/atom (I was trying to put together an extension). Depending on how whether you try to auth with an existing account or not, the server will return different headers if you fail to authenticate (identical headers removed): Non-existing account: $ curl -u victor.andreez -v https://mail.google.com/mail/feed/atom < HTTP/1.1 401 Unauthorized Existing account: $ curl -u victor.andree -v https://mail.google.com/mail/feed/atom < HTTP/1.1 401 Unauthorized < WWW-Authenticate: BASIC realm="New mail feed" If you attempt the same requests with XMLHttpRequest, only the latter will display a login sheet (since there won't be an account to "login" to otherwise, I presume the Google engineers thought). According to the specs, the sheet should never be displayed. Reproducing with XMLHttpRequest: xhr = new XMLHttpRequest(); // No account xhr.open("GET", "https://mail.google.com/mail/feed/atom", true, "victor.andreez", "hunter2"); xhr.send(); // --> Failed to load resource: the server responded with a status of 401 (Unauthorized) // Existing account xhr.open("GET", "https://mail.google.com/mail/feed/atom", true, "victor.andree", "hunter2"); xhr.send(); // --> Failed to load resource: cancelled // + a stinking sheet!
As far as I can tell, WebKit behaves the same way as Firefox does here. Is that acurate? Is there a Mozilla bug for this?
Adding keyword InRadar since the bug description references radar bug 7497786 <rdar://problem/7497786>.
According to the spec, we should also not prompt the user if "Authorization" header is provided with setRequestHeader().
This is almost a duplicate of bug 8291.
This issue needs to be addressed. This is improper behavior according to the W3C spec. On the following page: http://www.w3.org/TR/XMLHttpRequest/ you can find these three paragraphs: "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, source origin and the request URL are same origin, Authorization is not in the list of author request headers, request URL's username is the empty string and request URL's 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." The latest version of Safari (5.1.7) on Windows does not do this. The browser always prompts for a username and password. No other browser, IE 9, 10, 11, Firefox, Chrome, nor Opera does this. They all obey the specification and behave similarly.