Webkit's XHR cannot currently be used to authenticate a user using HTTP Authentication as the username and password parameters passed to open() are ignored. If requesting a protected resource using XHR the browser responds to the server's challenge by showing the HTTP auth dialog. Looking at the headers sent by Firefox it's XHR implementation sends the username and password in the URL initially, the server responds with the authentication challenge and XHR resends the request with the appropriate Authorization header. Maybe Webkit's XHR should do the same? One limitation of Firefox's XHR implementation, and probably IEs also, 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. It would be cool if Webkit could provide more flexibility in this case.
<rdar://problem/4335156> XMLHttpRequest ignores username/password passed to open() passed to open()
Created attachment 7601 [details] test case Debug builds hit an assertion in KURL::setUser().
Created attachment 7602 [details] proposed fix Hmm, simply unblocking KURL::setUser() and setPass() seems to make things work, at least when the passed login/password are correct. Since the desired behavior in the case when login/password are incorrect is not completely clear (and this is different code anyway), maybe we should investigate it in a separate step. Currently, sync requests silently fail, while async ones cause an auth dialog to be displayed, but entering correct login/password seems to have no effect.
Comment on attachment 7602 [details] proposed fix It looks sane to me. I wonder how this interacts with keychain passwords, etc. I would be interested to know if the code was turned off for a reason.
From the logs it looks like it was just never turned on after merging. Not sure why it wasn't turned on to begin with though. Darin or ken would know: swingtop [29320:OpenSource]% svn log -r 4628 [/Volumes/Stuff/Projects/WebKit/OpenSource] ------------------------------------------------------------------------ r4628 | darin | 2003-07-11 15:38:03 -0700 (Fri, 11 Jul 2003) | 30 lines Reviewed by Ken. - roll in change from KHTML to remove user and password from referrer * khtml/khtml_part.cpp: (KHTMLPart::begin): Call setUser(""), setPass(""), and setRef(""), then also set the referrer to "" if the protocol does not start with http. * kwq/WebCoreBridge.mm: (-[WebCoreBridge referrer]): Remove check to exclude file URL referrers because KHTMLPart now excludes all non-http referrers. * kwq/KWQKURL.h: Add setUser and setPass functions. Also sort by order within the URL so it's clear no methods are omitted. * kwq/KWQKURL.mm: (KURL::setUser): Added. Adds or removes the username, adding or removing delimiters as needed. For now only the remove part is compiled in. (KURL::setPass): Added. Adds or removes a password, adding or removing delimiters as needed. For now only the remove part is compiled in. * kwq/KWQString.h: Add QSTRING_NULL macro to allow us to work around the fact that there is no global QString::null object in KWQ without having to do a relatively ineffecient conversion from a non-constant char * of 0 each time. We can use this anywhere QString::null appears and perhaps get some small code savings or performance boost. - small cleanup * kwq/KWQTextCodec.mm: (QTextCodec::fromUnicode): Remove unneeded checks that repeat optimizations I already put in QString. ------------------------------------------------------------------------
Comment on attachment 7602 [details] proposed fix Nice! r=me
Landed, r13751. For older versions, embedding the credentials in URL, rather then passing them as separate parameters should work: http://user:password@host/path. Reporter, could you please open a new bug for the case when the supplied credentials are incorrect? You are proposing that the behavior should be configurable - do you already have some specific API in mind? Has this issue been discussed in Mozilla community, by any chance?
I've opened a new bug proposing that XHR should provide some means for handling an authentication failure, see http://bugzilla.opendarwin.org/show_bug.cgi?id=8291
Mass moving XML DOM bugs to the "DOM" Component.