views:

109

answers:

1

I have an app that logs in via .htaccess. When the person wants to logout, I use:

function logout2() { try{

  var agt=navigator.userAgent.toLowerCase();
  if (agt.indexOf("msie") != -1) {
  // IE clear HTTP Authentication
  document.execCommand("ClearAuthenticationCache");
 } 
 else {
   var xmlhttp = createXMLObject();
xmlhttp.open("GET",".force_logout_offer_login_mozilla",true,"logout","");
xmlhttp.send("");
xmlhttp.abort();
}
} catch(e) {

alert("there was an error");
 }

function createXMLObject() {
  try {   if (window.XMLHttpRequest) {    xmlhttp =

new XMLHttpRequest(); } // code for IE else if (window.ActiveXObject) {
xmlhttp=new ActiveXObject("Microsoft.XMLHTTP");
} } catch (e) { xmlhttp=false } return xmlhttp; }

The problem is that this is not working for Safari, the person is always logged in using the initial credentials, even closing and reopening the browser. Does anybody know how to handle this?

A: 

It is an undocumented quirk of Mozilla's XMLHttpRequest implementation that sending bad auth in an XMLHttpRequest affects the auth used by the main browser in the future. Leveraging this to provide logout is a reasonable hack for now, but I wouldn't count on it working in the future, let alone on other browsers.

The only reliable cross-browser way I know of to allow a logout function is to redirect the user to a page that will 401 them when they pass in valid auth credentials, instead of invalid ones. Then a logged-in user will be greeted with an auth prompt, which they can put bad auth in (normally you tell them to just leave the user/pass fields blank). The script responds positively (eg 302) to the bad auth and the browser remembers it for the future, overwriting the previous good auth.

Unfortunately this process does require some significant user interaction. This is one of the drawbacks of HTTP Authentication.

bobince