Bug 11640 – XMLHttpRequest produces undefined:undefined HTTP authentication

• Component: XML
• Status: RESOLVED FIXED

[Gary-adam Shannon]

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

[Gary-adam Shannon]

RoR bug report here (and patch): http://dev.rubyonrails.org/ticket/6638

[Mark Rowe (bdash)]

Thanks for the bug report!

[Alexey Proskuryakov]

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.

[Rob Buis]

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.

[Alexey Proskuryakov]

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.
-----------------------------

[Rob Buis]

(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.

[Rob Buis]

Comment on attachment 11562 [details]
proposed fix

r=me

[Alexey Proskuryakov]

Committed revision 17842.