Bug 8291 - XMLHttpRequest needs to be extended before it can provide an alternative interface to the browser's dialog for HTTP auth
Summary: XMLHttpRequest needs to be extended before it can provide an alternative inte...
Status: NEW
Alias: None
Product: WebKit
Classification: Unclassified
Component: XML (show other bugs)
Version: 420+
Hardware: Macintosh OS X 10.4
: P2 Enhancement
Assignee: Nobody
URL:
Keywords:
Depends on:
Blocks: 10489
  Show dependency treegraph
 
Reported: 2006-04-10 01:47 PDT by Adam Ratcliffe
Modified: 2007-03-14 14:13 PDT (History)
4 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Adam Ratcliffe 2006-04-10 01:47:25 PDT
A limitation of XHR is that it's not possible to control whether the browser's HTTP auth dialog is shown when invalid credentials are sent with the XHR request. This limits its usefulness in providing an alternative interface to the browser's dialog for HTTP auth.

This issue has been discussed in the Mozilla community and alternatives suggested but so far not implemented, see:

https://bugzilla.mozilla.org/show_bug.cgi?id=282547
https://bugzilla.mozilla.org/show_bug.cgi?id=221943

A simple solution would be for the open() method to accept a callback for handling an authentication failure.  If open() was called without a reference to a callback function, or the callback function returned FALSE the HTTP auth dialog could be displayed.
Comment 1 Alexey Proskuryakov 2006-04-10 02:42:34 PDT
Additionally, I think that our current implementation is inconsistent and/or broken (only shows the dialog for async requests, but doesn't seem to actually use the typed in credentials).
Comment 2 Alexey Proskuryakov 2006-06-10 05:21:54 PDT
(In reply to comment #1)
> Additionally, I think that our current implementation is inconsistent and/or
> broken (only shows the dialog for async requests,

This is bug 8342.

> but doesn't seem to actually use the typed in credentials).

Looks like an NSURLConnection bug, rdar://4581439. It is probably possible to work around it in WebKit (by removing credentials from the URL passed to Foundation and handling them manually) , but I'm not sure if it's worth it.