Summary: | XMLHttpRequest ignores username/password passed to open() | ||||||||
---|---|---|---|---|---|---|---|---|---|
Product: | WebKit | Reporter: | Adam Ratcliffe <adam> | ||||||
Component: | DOM | Assignee: | Alexey Proskuryakov <ap> | ||||||
Status: | RESOLVED FIXED | ||||||||
Severity: | Normal | CC: | ap, cdumez, darin | ||||||
Priority: | P2 | Keywords: | InRadar | ||||||
Version: | 420+ | ||||||||
Hardware: | Mac | ||||||||
OS: | OS X 10.4 | ||||||||
Attachments: |
|
Description
Adam Ratcliffe
2006-03-20 11:56:22 PST
<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. |