Opened 7 years ago

Closed 7 years ago

Last modified 7 years ago

#14525 closed defect (invalid)

dojo.xhr Basic Auth broken

Reported by: haysmark Owned by:
Priority: high Milestone: tbd
Component: Core Version: 1.7.1
Keywords: Cc:
Blocked By: Blocking:

Description

The dojo.xhr docs say we implement HTTP Basic Auth. We actually implement the auth by passing the username and password to the native xhr.open call and hope the browser takes care of it.

What browsers typically do is prepend these parameters to the URL, like this:

http://username:password@myhost.com

This doesn't actually do the Basic Auth though (the above format is from an ancient RFC). Some browsers (FF 3.6) also append the Basic Auth HTTP header like this:

Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==

Sadly, only FF 3.6.x seems to append this crucial header. Even IE stopped thanks to a certain Security Update from Microsoft. True to the Dojo form, we should be appending the Basic Auth header ourselves so that Basic Auth works consistently across all browsers.

Technical note: the convenient btoa method isn't in IE6. We would have to implement Base64 encoding ourselves.

Change History (4)

comment:1 Changed 7 years ago by haysmark

Resolution: invalid
Status: newclosed

Hmm so last night this was the behavior I was seeing. I try again today and of course it is working just fine and dandy. Will need to investigate more...

comment:2 Changed 7 years ago by Adam Peller

FWIW, we do implement basic encoding in dojox.encoding. Perhaps a basic auth feature could be implemented a mixin, but as things stand today, xhr's behavior should probably be documented as browser specific.

comment:3 in reply to:  1 ; Changed 7 years ago by Adam Peller

Replying to haysmark:

Hmm so last night this was the behavior I was seeing. I try again today and of course it is working just fine and dandy. Will need to investigate more...

Does the server process the url parameters as if it were sent as a base64 header? If so, it may end up in the session?

comment:4 in reply to:  3 Changed 7 years ago by haysmark

Replying to peller:

Does the server process the url parameters as if it were sent as a base64 header? If so, it may end up in the session?

No, this is definitely happening on the browser side. When I look in the network trace, whether or not when I clear the session/cache/restart the server, all of the browsers consistently send the corresponding Authentication header:

Authorization:Basic dXNlcm5hbWU6cGFzc3dvcmQ=

(that is literally "username:password")

I think the reason I was not seeing the header the other day was because I originally required a login for the whole server. I suspect that because I was already logged in, the browser saw no need to log in again for the xhr. So when I changed it to require the login for just the xhr's resource, I saw the header consistently.

Note: See TracTickets for help on using tickets.