How do I keep Firefox from prompting for username/password with HTTP Basic Auth with JQuery AJAX?

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

Estovers

Note the follow-up at #929467 . – Counterproductive

Answer 1

In case you haven't read it:

How can I supress the browser's authentication dialog?

Doesn't look too promising :)

Moonlight

Answer 2

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.

Edwin

As indicated in related question's answer comment. The WWW-Authenticate should indicates a one (or more) valid challenge. And I think too None isn't a real one. #1748874 – Hephzipa

Please look here for a solution on how to solve this with Java and Spring Security: #19080187 – Edwin

It is the solution, albeit looking irregular. ietf.org/rfc/rfc2617.txt (4.6) specifies multiple schemes, however does not restrict to Basic, Digest etc. So it's up to client (browser) to support a scheme or not, if scheme is not supported, the browser does no user interaction. I use this approach for transparent fallback from Windows SSO ( SPNEGO ) to a simple form login. BTW: only works reliably in Chrome+IE when accessing server via hostname; don't use IPs. – Monecious

@Monecious I don't know how you got a transparant fallback going, so I "fixed it" by creating an API endpoint "testGSS" which tries to evaluate as many parameters as possible from the client (which network, which browser, etc...) and when there is a high likelyhood Negotiate auth is going to work, sends a positive reply. The web app then tries Negotiate auth and when that succeeds, stores a flag in localStorage. Next time when the web app sees this flag it immediatly goes to the Negotiate auth endpoint, all other cases go to the form based method. – Offbeat

Answer 3

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 =)

Ludicrous

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.

Sexuality