[ACCEPTED]-Is there a browser equivalent to IE's ClearAuthenticationCache?-cross-browser

I've come up with a fix that seems fairly 12 consistent but is hacky and I'm still not happy with it.

It does work 11 though :-)

1) Redirect them to a Logoff page

2) On 10 that page fire a script to ajax load another 9 page with dummy credentials (sample in jQuery):

$j.ajax({
    url: '<%:Url.Action("LogOff401", new { id = random })%>',
    type: 'POST',
    username: '<%:random%>',
    password: '<%:random%>',
    success: function () { alert('logged off'); }
});

3) That 8 should always return 401 the first time 7 (to force the new credentials to be passed) and 6 then only accept the dummy credentials (sample 5 in MVC):

[AcceptVerbs(HttpVerbs.Post)]
public ActionResult LogOff401(string id)
{
    // if we've been passed HTTP authorisation
    string httpAuth = this.Request.Headers["Authorization"];
    if (!string.IsNullOrEmpty(httpAuth) &&
        httpAuth.StartsWith("basic", StringComparison.OrdinalIgnoreCase))
    {
        // build the string we expect - don't allow regular users to pass
        byte[] enc = Encoding.UTF8.GetBytes(id + ':' + id);
        string expected = "basic " + Convert.ToBase64String(enc);

        if (string.Equals(httpAuth, expected, StringComparison.OrdinalIgnoreCase))
        {
            return Content("You are logged out.");
        }
    }

    // return a request for an HTTP basic auth token, this will cause XmlHttp to pass the new header
    this.Response.StatusCode = 401; 
    this.Response.StatusDescription = "Unauthorized";
    this.Response.AppendHeader("WWW-Authenticate", "basic realm=\"My Realm\""); 

    return Content("Force AJAX component to sent header");
}

4) Now the random string credentials 4 have been accepted and cached by the browser 3 instead. When they visit another page it 2 will try to use them, fail, and then prompt 1 for the right ones.

A couple of notes. A few people have said 17 that you need to fire off a ajax request 16 with invalid credentials to get the browser 15 to drop it's own credentials.

This is 14 true but as Keith pointed out, it is essential 13 that the server page claims to accept these 12 credentials for this method to work consistently.

On 11 a similar note: It is NOT good enough for 10 your page to just bring up the login dialog 9 via a 401 error. If the user cancels out 8 of the dialog then their cached credentials 7 are also unaffected.

Also if you can please 6 poke MOZILLA at https://bugzilla.mozilla.org/show_bug.cgi?id=287957 to add a proper fix for 5 FireFox. A webkit bug was logged at https://bugs.webkit.org/show_bug.cgi?id=44823. IE 4 implements a poor but functional solution 3 with the method:

document.execCommand("ClearAuthenticationCache", "false");

It is unfortunate that 2 we need to go to these lengths just to log 1 out a user.

Mozilla implemented the crypto object, available 15 via the DOM window object, which has the logout function 14 (Firefox 1.5 upward) to clear the SSL session 13 state at the browser level so that "the 12 next private operation on any token will 11 require the user password again" (see 10 this).

The crypto object seems to be an implementation 9 of the Web Crypto API, and according to this document, the DOMCrypt 8 API will add even more functions.

As stated 7 above Microsoft IE (6 upward) has: document.execCommand("ClearAuthenticationCache", "false")

I have 6 found no way of clearing the SLL cache in 5 Chrome (see this and this bug reports).

In case the 4 browser does not offer any API to do this, I 3 think the better we can do is to instruct 2 the user to close the browser.

Here's what 1 I do:

var agt=navigator.userAgent.toLowerCase();
if (agt.indexOf("msie") !== -1) {
    document.execCommand("ClearAuthenticationCache","false");
}
//window.crypto is defined in Chrome, but it has no logout function
else if (window.crypto && typeof window.crypto.logout === "function"){
    window.crypto.logout();
}
else{
    window.location = "/page/to/instruct/the/user/to/close/the/browser";
}

I've been searching for a similar solution 14 and came across a patch for Trac (an issue 13 management system) that does this.

I've 12 looked through the code (and I'm tired, so 11 I'm not explaining everything); basically 10 you need to do an AJAX call with guaranteed invalid credentials 9 to your login page. The browser will get a 401 and know it 8 needs to ask you for the right credentials 7 next time you go there. You use AJAX instead 6 of a redirect so that you can specify incorrect 5 credentials and the browser doesn't popup 4 a dialog.

On the patch (http://trac-hacks.org/wiki/TrueHttpLogoutPatch) page they use very 3 rudimentary AJAX; something better like 2 jQuery or Prototype, etc. is probably better, although 1 this gets the job done.

Why not use FormsAuth, but against ActiveDirectory 4 instead as per the info in this thread. It's just as 3 (in)secure as Basic Auth, but logging out 2 is simply a matter of blanking a cookie 1 (or rather, calling FormsAuthentication.SignOut)

Well, I've been browsing around Bugzilla 4 for a bit now and seemingly the best way 3 you can go for clearing the authentication 2 would be to send non-existant credentials.

Read 1 more here: https://bugzilla.mozilla.org/show_bug.cgi?id=287957