其实很简单。

只需在浏览器中访问以下内容，并使用错误的凭据: http://username:password@yourdomain.com

这应该会“让你退出”。

下面是一个使用jQuery的非常简单的Javascript示例:

function logout(to_url) {
    var out = window.location.href.replace(/:\/\//, '://log:out@');

    jQuery.get(out).error(function() {
        window.location = to_url;
    });
}

此登录用户退出而不再次显示浏览器登录框，然后将其重定向到注销页面

以下功能在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)有很多方法可以做到这一点，我创建了两个登录后端，一个接受注销用户和一个不接受。我的正常登录页面使用一个不接受，我的注销页面使用一个接受它。

基本身份验证不是为管理注销而设计的。你可以这样做，但不是完全自动的。

你所要做的就是让用户点击登出链接，然后发送一个“401未授权”作为响应，使用与你发送的请求登录的正常401相同的域和URL文件夹级别。

接下来，他们必须被引导输入错误的凭证。一个空白的用户名和密码，作为回应，您发回一个“您已成功注销”页面。错误的/空白的凭证将覆盖之前的正确凭证。

简而言之，登出脚本颠倒了登录脚本的逻辑，只有在用户没有传递正确的凭据时才返回成功页面。

问题是这个有点奇怪的“不要输入密码”的密码框是否能让用户接受。试图自动填充密码的密码管理器也会在这里起到阻碍作用。

编辑添加以回应评论:重新登录是一个稍微不同的问题(除非你显然需要两步注销/登录)。您必须拒绝(401)第一次访问重新登录链接的尝试，然后接受第二次(可能有不同的用户名/密码)。有几种方法可以做到这一点。一种方法是在登出链接中包含当前用户名。/relogin?username)，并在凭据与用户名匹配时拒绝。

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

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

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

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

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

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

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