Bug 11640 - XMLHttpRequest produces undefined:undefined HTTP authentication
Summary: XMLHttpRequest produces undefined:undefined HTTP authentication
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: XML (show other bugs)
Version: 420+
Hardware: Macintosh OS X 10.4
: P2 Major
Assignee: Alexey Proskuryakov
URL: http://www.fulgore.net/prototype.js
Keywords:
Depends on:
Blocks:
 
Reported: 2006-11-17 20:42 PST by Gary-adam Shannon
Modified: 2006-11-18 06:02 PST (History)
2 users (show)

See Also:


Attachments
proposed fix (6.11 KB, patch)
2006-11-18 03:31 PST, Alexey Proskuryakov
rwlbuis: review+
Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Gary-adam Shannon 2006-11-17 20:42:14 PST
Prototype line 775 seems to be culprit.

If you are authenticated to a basic realm and then use XMLHttpRequest through Prototype - it results in a request to http://undefined:undefined@hostname which in turn prevents you from being able to complete the request.

Some chat transcript from bdash below:

20:13 < bdash> the prototype code calls transport.open(this.options.method.toUpperCase(), this.url,
               this.options.asynchronous, this.options.username, this.options.password);
20:14 < bdash> this.options is an object consisting of some default fields, merged with the configuration you pass to Ajax.Request
20:14 < bdash> there is no username or password key, so this.options.username and this.options.password are both undefined
20:15 < bdash> our behaviour obviously differs from Firefox in the case of undefined, though the work-in-progress XMLHttpRequest specification says that no username and password should be indicated by 'null'

Extent of browser testing as follows:

IE Windows - Request completes ok
FF Windows - Request completes ok
FF OSX - Request completes ok
SF/WK OSX - Request fails
Comment 1 Gary-adam Shannon 2006-11-17 20:59:45 PST
RoR bug report here (and patch): http://dev.rubyonrails.org/ticket/6638
Comment 2 Mark Rowe (bdash) 2006-11-17 21:00:36 PST
Thanks for the bug report!
Comment 3 Alexey Proskuryakov 2006-11-18 03:31:51 PST
Created attachment 11562 [details]
proposed fix

We also have issues with null parameters (and the draft XHR spec also does), but this change seems straightforward and simple enough to be made right away.
Comment 4 Rob Buis 2006-11-18 04:29:46 PST
Hi Alexey,

(In reply to comment #3)
> Created an attachment (id=11562) [edit]
> proposed fix
> 
> We also have issues with null parameters (and the draft XHR spec also does),
> but this change seems straightforward and simple enough to be made right away.

Comparing with the RoR patch, there seems to be a difference. That one passes user and
password string only if both are defined, your patch passes both when user is defined but
password is undefined. I am not too familiar with XHR (yet), but I can imagine this would not make sense?
Cheers,

Rob.
Comment 5 Alexey Proskuryakov 2006-11-18 04:44:02 PST
The patch makes open(..., "login", undefined) work like open(..., "login"), which I think is correct. How the latter should work is an open issue still; quoting the current XHR editor's draft:

-----------------------------
Issue: Need to look at the password argument. What syntax does it need to match. Can it be UTF-8 on transmission? When it's omitted, do UAs still use the user argument? IE doesn't.
-----------------------------
Comment 6 Rob Buis 2006-11-18 05:27:26 PST
(In reply to comment #4)
> Hi Alexey,
> 
> (In reply to comment #3)
> > Created an attachment (id=11562) [edit]
> > proposed fix
> > 
> > We also have issues with null parameters (and the draft XHR spec also does),
> > but this change seems straightforward and simple enough to be made right away.
> 
> Comparing with the RoR patch, there seems to be a difference. That one passes
> user and
> password string only if both are defined, your patch passes both when user is
> defined but
> password is undefined. I am not too familiar with XHR (yet), but I can imagine
> this would not make sense?

ap explained that above scenario behaves like providing a user without a password, which still is an open issue for the specification. For that same reason there are no tests for this in basic-realm.html yet. With that in mind, I am going to r+ it.
Cheers,

Rob.
Comment 7 Rob Buis 2006-11-18 05:29:10 PST
Comment on attachment 11562 [details]
proposed fix

r=me
Comment 8 Alexey Proskuryakov 2006-11-18 06:02:55 PST
Committed revision 17842.