bobince对这个问题的补充回答是…

使用Ajax，您可以将“注销”链接/按钮连接到Javascript函数。让这个函数发送带有错误用户名和密码的XMLHttpRequest。这应该会得到401。然后设置文档。位置返回到预登录页面。这样，用户将永远不会在注销期间看到额外的登录对话框，也不必记得输入错误的凭据。

以下功能在Firefox 40、Chrome 44、Opera 31和IE 11上均已确认有效。 Bowser用于浏览器检测，也使用jQuery。 —“secUrl”为密码保护区域的url，用户可以从该url退出。 —“redirUrl”为非密码保护区域的url(注销成功页面)。 你可能想增加重定向计时器(目前是200ms)。

function logout(secUrl, redirUrl) { if (bowser.msie) { document.execCommand('ClearAuthenticationCache', 'false'); } else if (bowser.gecko) { $.ajax({ async: false, url: secUrl, type: 'GET', username: 'logout' }); } else if (bowser.webkit) { var xmlhttp = new XMLHttpRequest(); xmlhttp.open("GET", secUrl, true); xmlhttp.setRequestHeader("Authorization", "Basic logout"); xmlhttp.send(); } else { alert("Logging out automatically is unsupported for " + bowser.name + "\nYou must close the browser to log out."); } setTimeout(function () { window.location.href = redirUrl; }, 200); }

根据我上面读到的内容，我得到了一个适用于任何浏览器的简单解决方案:

1)在你登出页面，你调用ajax到你的登录后端。您的登录后端必须接受注销用户。一旦后端接受，浏览器将清除当前用户并假定为“注销”用户。

$.ajax({
    async: false,
    url: 'http://your_login_backend',
    type: 'GET',
    username: 'logout'
});      

setTimeout(function () {
    window.location.href = 'http://normal_index';
}, 200);

2)现在当用户回到正常的索引文件时，它将尝试自动进入系统，用户“logout”，在第二次你必须通过回复401来调用登录/密码对话框来阻止它。

3)有很多方法可以做到这一点，我创建了两个登录后端，一个接受注销用户和一个不接受。我的正常登录页面使用一个不接受，我的注销页面使用一个接受它。

 function logout(url){
    var str = url.replace("http://", "http://" + new Date().getTime() + "@");
    var xmlhttp;
    if (window.XMLHttpRequest) xmlhttp=new XMLHttpRequest();
    else xmlhttp=new ActiveXObject("Microsoft.XMLHTTP");
    xmlhttp.onreadystatechange=function()
    {
        if (xmlhttp.readyState==4) location.reload();
    }
    xmlhttp.open("GET",str,true);
    xmlhttp.setRequestHeader("Authorization","Basic xxxxxxxxxx")
    xmlhttp.send();
    return false;
}

使用会话ID (cookie) 使服务器上的会话ID失效 不接受会话id无效的用户

实际上，我认为基本身份验证的目的是用于静态页面，而不是用于任何复杂的会话管理或CGI页面。

因此，当需要会话管理时，你应该设计一个经典的“登录表单”来查询用户和密码(可能也是第二个因素)。 CGI表单处理程序应该将成功的身份验证转换为服务器上记住的会话(ID)(在cookie中或作为URI的一部分)。

然后，通过使服务器(和客户端)“忘记”会话。 另一个优点是(即使加密后)用户和密码不会随每个请求一起发送到服务器(而是发送会话ID)。

如果服务器上的会话ID与执行的“最后一个动作”的时间戳相结合，则会话超时可以通过比较该时间戳与当前时间来实现: 如果时间跨度太大，则通过忘记会话ID来“超时”会话。

对无效会话的任何请求都将导致重定向到登录页面(或者如果您想让它更舒服，您可以使用“重新验证表单”再次请求密码)。

作为概念的证明，我实现了一个完全无cookie的会话管理，它完全基于URI(会话ID始终是URI的一部分)。 然而，完整的代码对于这个答案来说太长了。

当希望处理数千个并发会话时，必须特别注意性能。