[PATCH] Safari HTTP auth problem because of changes in Ajax

I have also come across #4192 which looks to be identical to my patch and should also be closed with this bug if this patch is accepted (and perhaps closed in general because username and password can now be specified as of r5448).

Perhaps something like this is better:

var args = [this.options.method.toUpperCase(),
  this.url, this.options.asynchronous]

if(this.options.username) args.concat(
  [this.options.username, this.options.password || ''])

this.transport.open.apply(this.transport, open_args)

It's prettier and you don't have to specify a password if you want to send an empty one.

Thanks for the report!

This doesn't just break when you create a custom Ajax request, if also breaks requests with all the ajax helpers.

We should definetely come up with a method of testing this, should be reasonably doable with the automatic unit tests and some hackery to the WEBRick thingy it uses. I'd gladly apply this, currently I'm a bit out of time to write those myself.

Replying to jmecham:

r5448 added code to allow the specification of a username and password to use for an XMLHTTPRequest, but even if values are not provided they are added to the request. In Safari, this defaults to "undefined" resulting in requests to http://undefined:undefined@example.com/ (which breaks my custom HTTP Authorization header set with "requestHeaders" ('Authorization: Basic XXXXXXXXX'). The username and password should not be set for the request if they have not been specified.

I need this patch, or something like it, to be applied soon.

I just updated to the new version of Scriptaculous (1.6.5) for my web application, which is built on Zope 3, not Rails. Zope 3 and its predecessors have long had a rich security model and easy support for HTTP Auth, so I make use of it quite often. Since applying Scriptaculous 1.6.5, which uses a version of Prototype.js that includes the Ajax username/password changes, my application pops up authentication challenges all over the place and they're hard to get rid of. Prior to these changes, the browser sent along the same authentication credentials it would send along to any other resource that requested authentication. I need that behavior to continue. I don't have access to a users name and password, and would hate to have to send it along in a rendered page in plain text if I did. If the browser and underlying server software are taking care of authentication for me already, I shouldn't have to manually specify the username and password with every XMLHttpRequest any more than I'd have to specify it on every link that pointed to an image or CSS file or page that required authentication.

I've investigated a bit further here. First thing, of course the patch needs to be applied as it breaks Safari. mislav: note that your approach seems to fail (the apply() call seems to have a bug with Safari when used with XMLHttpRequest.open).

On the other hand, the username/password combination given to XMLHttpRequest.open() doesn't do anything (tested Firefox on Safari). It does _not_ send along the credentials. If I manually add an Authorization header, it works. Because of this, I propose to remove the username/password option completely. Note that the test case in #4192 doesn't work for me either (when using the open() method)-- keep in mind to completely close the browser between tests to clear out the auth cache.

I'm adding a patch here, for playing around with this. Let me know what you think. If anyone can come up with an explanation, please do so-- I'm out of guessing.

Note: to play around with the patch, apply, then do:

$ rake test_units TESTS=ajax BROWSERS=firefox

Use firebug to have a look at the headers that get sent.

for playing with the authorization header

Madrobby, thanks for taking time for throughly test this. Your findings are indeed interesting.

How about we keep username/password options and throw in some base64_encode() like this one:

// This code was written by Tyler Akins and has been placed in the
// public domain.  It would be nice if you left this header intact.
// Base64 code from Tyler Akins -- http://rumkin.com

var keyStr = "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+/=";

function encode64(input) {
   var output = "";
   var chr1, chr2, chr3;
   var enc1, enc2, enc3, enc4;
   var i = 0;

   do {
      chr1 = input.charCodeAt(i++);
      chr2 = input.charCodeAt(i++);
      chr3 = input.charCodeAt(i++);

      enc1 = chr1 >> 2;
      enc2 = ((chr1 & 3) << 4) | (chr2 >> 4);
      enc3 = ((chr2 & 15) << 2) | (chr3 >> 6);
      enc4 = chr3 & 63;

      if (isNaN(chr2)) {
         enc3 = enc4 = 64;
      } else if (isNaN(chr3)) {
         enc4 = 64;
      }

      output = output + keyStr.charAt(enc1) + keyStr.charAt(enc2) + 
         keyStr.charAt(enc3) + keyStr.charAt(enc4);
   } while (i < input.length);
   
   return output;
}

Replying to mislav:

How about we keep username/password options and throw in some base64_encode() like this one:

We can-- but should we? The username/password thing is probably a use case not needed by most people. On the other hand base64 en- and decoding could be a nice-to-have for String.prototype. But it seems a bit like a case of featuritis.

Replying to madrobby:

The username/password thing is probably a use case not needed by most people.

Probably. Here's what we can do: throw out the options completely (as you suggested) and create an article on the documentation site (I can take care of that part) describing how to authenticate with the header and providing the base64_(en|de)code for copy/paste. After that we can listen to the feedback of the community and decide upon the issue for release 2.

How does that sound?

Replying to mislav:

How does that sound?

Sounds good to me. :)

Replying to mislav:

Replying to madrobby:

The username/password thing is probably a use case not needed by most people.

Probably. Here's what we can do: throw out the options completely (as you suggested) and create an article on the documentation site (I can take care of that part) describing how to authenticate with the header and providing the base64_(en|de)code for copy/paste. After that we can listen to the feedback of the community and decide upon the issue for release 2. How does that sound?

Btw, wanna look into a patch for this? ;)

Just to make sure this stays on the top...

(In [5741]) Prototype: * Remove support for HTTP authorization in Ajax calls introduced with #6366. Closes #6638 [jmecham]. This fixes a regression issue where Safari wouldnt work with sites that use HTTP authorization schemes, plus it never really worked in the first place-- see #6638 for discussion.