Spring Security SecurityContextHolder.getContext().getAuthentication() 返回 null答案

【问题标题】：Spring Security SecurityContextHolder.getContext().getAuthentication() returns nullSpring Security SecurityContextHolder.getContext().getAuthentication() 返回 null
【发布时间】：2013-07-08 04:09:42
【问题描述】：

我已经实现了一个映射到特定 URL "/partner/login" 的自定义安全机制，我在其中使用我自己的子类 AbstractAuthenticationProcessingFilter 生成一个子类 AbstractAuthenticationToken 由 AuthenticationProvider 的实现进行身份验证。成功后，我调用一个 SimpleUrlAuthenticationSuccessHandler，它将尝试重定向到“/UserProfile”。此"/partner/login" 处理来自我们其中一位合作伙伴的 SSO 请求。而在开发中，我们的内部登录过程是使用 Spring Security 的默认登录形式模拟的，这就是 auto-config 为 true 的原因。

最初我使用以下（spring security）配置进行开发：

<http  auto-config="true">
    <intercept-url pattern="/**/*.jsp" access="ROLE_USER, ROLE_PARTNER_USER"/>
    <custom-filter after = "FORM_LOGIN_FILTER" ref = "partnerSsoAuthFilter"/>
</http>

现在按预期工作，在重定向到“/UserProfile”后，我从 SecurityContextHolder 获取了 Authentication 对象

一旦我在使用自定义过滤器链图的生产（弹簧安全）配置中使用这些，问题就开始了。（我们在生产中使用 CAS 进行自己的登录）

<bean id="springSecurityFilterChain" class="org.springframework.security.web.FilterChainProxy">
    <sec:filter-chain-map path-type="ant">
        <sec:filter-chain pattern="/partner/login" filters="sif,partnerSsoAuthFilter,etfPartner,fsi" />
        <sec:filter-chain pattern="/" filters="casValidationFilter, wrappingFilter" />**
        <sec:filter-chain pattern="/secure/receptor" filters="casValidationFilter" />
        <sec:filter-chain pattern="/j_spring_security_logout" filters="logoutFilter,etf,fsi" />
        ***More filters***
    </sec:filter-chain-map>
</bean>

这里的 sif,etf,fsi 是常规的 SecurityContextPersistenceFilter、ExceptionTranslationFilter 和 FilterSecurityInterceptor。

使用此配置，当重定向到“/UserDetails”时SecurityContextHolder.getContext().getAuthentication() 返回null，但我仍然可以访问放置在会话中的身份验证对象。

我对这种行为感到困惑。在这两种情况下，我都对 "/partner/login" 使用相同的自定义过滤器/提供者/令牌等。为什么在一种情况下 getAuthentication() 不为空，而在另一种情况下为空？任何帮助都会很棒。 TIA。

【问题讨论】：

您使用哪个版本的 Spring Security？
Spring Security 版本为 3.1.1
你解决过这个问题吗？请分享您的解决方案..

标签： java spring spring-security servlet-filters

【解决方案1】：

我有一个想法，但我完全不确定（我对 SS+CAS 没有任何经验，我不喜欢在 conf 中手动声明 SS 过滤器）。我知道有一个SecurityContextPersistenceFilter 负责填充SecurityContextHolder。请检查它是否在您的开发配置中触发？如果它被解雇，请为您的生产环境检查同样的事情。希望这会有所帮助。

【讨论】：

是的，在这两种情况下，SecurityContextPersistenceFilter#doFilter() 在 SimpleUrlAuthenticationSuccessHandler#handle() 被触发后被触发。
如果我告诉 SecurityContextPersistenceFilter 如果响应代码为 302 时不要清除上下文怎么办？
我看不出有什么不同。无论如何，它将在下一个请求开始时填充。