Spring安全-无法注销

Question

我使用基本 HTTP 身份验证通过基本 LDAP 授权改造了我的 GWT/GXT 应用程序。当我启动新浏览器时，它运行良好 - 我收到提示并获得针对公司 LDAP 的授权。我的问题 - 除非关闭/重新打开浏览器，否则我无法注销。我可以调试并查看如何调用 SecurityContextLogoutHandler#logout 并执行以下代码

    if (invalidateHttpSession) {
        HttpSession session = request.getSession(false);
        if (session != null) {
            session.invalidate();
        }
    }

    SecurityContextHolder.clearContext();

但是，当站点重新加载时，它似乎没有任何效果，并且我永远不会收到另一个 HTTP 身份验证提示，除非重新启动浏览器（甚至清除缓存/cookie 没有帮助）。这是 applicationContext.xml 的相关部分

<security:http auto-config='true'>
    <security:intercept-url pattern="/reports/**" access="ROLE_USER" />
    <security:http-basic />
    <security:logout logout-url="/reports/logout" 
              logout-success-url="/reports/Application.html" />       
</security:http>

我尝试定义自定义 LogoutSuccessHandler 并执行 authentication.setAuthenticated(false); 但这也没有效果

我在这里缺少什么吗？非常感谢您的帮助

Answer 1

好的。在花费了太多时间之后，我想我已经有了答案。很简单 - 人们无法摆脱使用服务器端技术的基本 HTTP 身份验证。基本上，授权字符串在 HTTP 标头中进行 base-64 解码，当受保护的页面加载到浏览器时，安全令牌会重新填充，因此无论您在服务器上删除它的频率如何，每次调用该页面时它都会复活。我想可以在浏览器端玩一些聪明的技巧，但这将是脆弱且不可靠的。

对于我的情况，我将切换到基于表单的身份验证，无论如何，它可以更好地控制登录/注销过程。

我会继续接受我自己的答案，支持有人提出可接受的解决方案

Answer 2

波士顿基本上是正确的，你无法处理这个服务器端。然而，一些可用的黑客 。

简短的答案是将用户重定向到您希望他们登陆的 URL，但在其前面加上一个错误的用户名，后跟 @。因此，作为一个丑陋的例子，

<security:logout logout-url="/reports/logout" 
    logout-success-url="http://BADNAME@localhost/reports/Application.html" />

理想情况下，您应该实现一个处理程序来为您执行此操作，但出于说明目的，我认为这可以理解这个概念。

Answer 3

嗯……奇怪。我没发现你的配置有什么问题。您确实不需要定义任何自定义注销处理程序，因为它应该由 Spring Security 处理。

尝试一下，不要定义您的 logout-url，而是使用默认的注销链接：-

...
<security:logout logout-success-url="/reports/Application.html" />      
...

然后，使用 /j_spring_security_logout 注销。

这到底有用吗？

Answer 4

我坚信你是正确的。如果不在浏览器中执行，则无法使基本或摘要式身份验证无效。即使在那里，即使不是不可能，也将是极其困难的。坦率地说，我什至想不出一种方法可以在那里做到这一点（除了尝试关闭浏览器）。

正如您所指出的，问题在于，即使您使服务器端的所有内容无效，您也已经为浏览器提供了自动生成新的身份验证会话所需的一切。清除它的唯一方法是清除浏览器。即使重新启动服务器也不会清除浏览器创建新身份验证的能力，这很好地表明，如果不使基本或摘要身份验证合同无效，您将无法在服务器端完成此操作。

坦率地说，这似乎是浏览器中一个相当大的安全漏洞，因为在使用基本或摘要身份验证对站点进行身份验证后，您永远不应该让浏览器在开放访问服务器上运行。

表单身份验证可能是您最好的选择，因为除非您允许 Rememberme Cookie，否则您不会向浏览器提供有关如何恢复身份验证的信息。即使在那里，您也可以在注销时清除 cookie，这样会更容易。

Answer 5

我发现执行此操作的一种方法是返回 HTTP 401 响应。一些快速测试表明这适用于 Safari、Chrome 和 Chrome 的 macOS 版本。火狐。我使用的代码本质上与此相同：

@RequestMapping(value="/logout",method=RequestMethod.POST)
public void logout(HttpServletRequest request, HttpServletResponse response, HttpSession session) {
    session.setAttribute(LOGOUT_SESSION_KEY, true);
    response.setStatus(303);
    response.addHeader("Location", URL_OF_APPLICATION_HOME_PAGE);
}

@RequestMapping("/")
public void home(HttpServletRequest request, HttpServletResponse response, HttpSession session) {
    if (Boolean.TRUE.equals(session.getAttribute(LOGOUT_SESSION_KEY))) {
        if (request.getHeader("Authorization") != null) {
            session.invalidate();
        }

        response.setStatus(401);
        response.addHeader("WWW-Authenticate", "Basic realm=\"" + HTTP_BASIC_REALM + "\"");
        return;
    }

    /* Generate home page */
}

技巧是您通常需要返回 401 标头两次 - 在第一次之后，浏览器将使用其缓存的凭据重试（发送“Authorization”标头，此时我们销毁用户的旧会话），第二个似乎清除它们并提示登录。

Answer 6

<logout invalidate-session="true" logout-url="/reports/logout"
        logout-success-url="/reports/Application.html" />

只需将无效会话设置为“true”，看看它是否有效。

检查您的 web.xml 中是否存在此监听器：

<!-- Security: to listen session requests -->
<listener>
     <listener-class>org.springframework.security.web.session.HttpSessionEventPublisher</listener-class>
 </listener>

如果上述方法不起作用，那么您可以尝试以下解决方案。
我认为问题出在您的以下行，

<security:intercept-url pattern="/reports/**" access="ROLE_USER" />

上面的行意味着您将访问权限 ROLE_USER 添加到了“/reports/**”链接。
但注销后，您会为注销成功提供相同的网址。那么它将如何运作呢？
更改注销成功页面的位置，或者您可以在 http 标记中添加以下行。

<intercept-url pattern="/reports/Application.html" filters="none" />