Bug 7877 – XMLHttpRequest ignores username/password passed to open()

• Component: DOM
• Status: RESOLVED FIXED

[Adam Ratcliffe]

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.

[Eric Seidel (no email)]

<rdar://problem/4335156> XMLHttpRequest ignores username/password passed to open() passed to open()

[Alexey Proskuryakov]

Created attachment 7601 [details]
test case

Debug builds hit an assertion in KURL::setUser().

[Alexey Proskuryakov]

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.

[Eric Seidel (no email)]

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.

[Eric Seidel (no email)]

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.

------------------------------------------------------------------------

[Darin Adler]

Comment on attachment 7602 [details]
proposed fix

Nice! r=me

[Alexey Proskuryakov]

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?

[Adam Ratcliffe]

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

[Lucas Forschler]

Mass moving XML DOM bugs to the "DOM" Component.