如何使用JQuery AJAX使用HTTP Basic Auth阻止Firefox提示用户名/密码？

Question

I'm writing some browser side dynamic functionality and using HTTP Basic Auth to protect some resources. The user experience is very important and is highly customized.

Here's a simple test JQuery method that eventually will test if a user has supplied the right credentials in a form:

$(document).ready(function() {
    $("#submit").click(function() {
    var token = Base64.encode($('#username').val() + ':' + $('#password').val());        
    $.ajax({
      url: '/private',
      method: 'GET',
      async: false,
      beforeSend: function(req) {
        req.setRequestHeader('Authorization', 'test:password');
      },
      error: function(request, textStatus, error) {
        if (request.status == 401) {
          alert('401');
        }
      }
    });
    return false;
  });
});

If they are not allowed to access /private , at the moment they should see just the alert box. However, on Firefox, a browser-provided login form pops up (to retry with new credentials). Safari does not do this.

We want to completely control the experience with custom forms, fades, transitions, etc. How can I keep Firefox's default box from being shown? (If this will be an issue when we test for IE, I'd love to hear solutions there, too.)

Answer 1

The solution is to set the WWW-Authenticate header to something other than Basic . For example set it to:

WWW-Authenticate: None

or

WWW-Authenticate: FormBased

if you use form based login. Then the browser will not show you a login window.

Answer 2

Unfortunatly, I am hitting the same issue here.

In my opinion, Browsers should not give a prompt for an xmlhttprequest. I really wish someone would push that cause people are really wanting to move to jQuery for their auth needs.

Well here is the help I can give you, I found this jQuery Digest thing, I have no idea what it really does or anything, but if someone could take this code the right way, we could have a jquery digest auth system.

https://www.openhub.net/p/digestj

I would think with this handy new AuthDigestDomain option, we could have the above script rewritten or whatever and have the secured area 'linked' together and we could get past this problem once and for all. Well... best of luck =)

Answer 3

In case you haven't read it:

How can I supress the browser's authentication dialog?

Doesn't look too promising :)

Answer 4

I found somewhere a workaround of this authentication popup issue.

WWW-Authenticate: None

doesn't work for me, but I've added

'Authorization': 'Basic'

to the headers and it works like a charm.