本文详解 spring security 中如何正确配置多个自定义认证过滤器（如分别处理 get/post 请求），避免因过滤器顺序、重复授权配置或 `authorizerequests()` 分段调用导致的 401/403 错误。核心在于统一授权入口、合理使用 `addfilterbefore`/`addfilterafter`，并避免链式 dsl 的误用。
在 Spring Security 中，将多个自定义认证过滤器（如 FilterA 和 FilterB）直接通过 .addFilter() 连续追加，并配合多段 .authorizeRequests() 配置，是典型的设计误区。你遇到的现象——“第一个过滤器总失败，第二个却正常”——根本原因在于：
HttpSecurity 的 DSL 是状态累积型的，但 authorizeRequests() 不可重复调用生效：
每次调用 .authorizeRequests() 都会创建一个新的 ExpressionUrlAuthorizationConfigurer 实例，后续 .mvcMatchers(...).authenticated() 仅作用于该次配置块；只有最后一个 .authorizeRequests() 块的规则真正生效，前面的会被覆盖或忽略。这导致 /getrequest/** 的权限规则实际未生效，触发默认拒绝（401）。过滤器注册顺序 ≠ 请求匹配逻辑顺序：
即使 FilterA 先注册，若它未成功完成认证（如未设置 SecurityContext 或抛出异常），后续过滤器（如 FilterB）仍可能被调用，但此时 SecurityContextHolder 为空，FilterB 的 authenticationManager 将无法基于已有上下文工作，极易因空 principal 或重复认证引发 403。混合使用 authenticationManager() 和 authenticationProvider() 易引发委托冲突：
authenticationManager() 默认由 AuthenticationConfiguration 提供，已集成全局 AuthenticationProviders；而手动调用 .authenticationProvider(customAauthProvider()) 仅影响该配置块后的默认 manager，与 FilterB 中显式注入的 authenticationManager() 可能不一致，造成行为不可预测。
✅ 正确做法：统一入口 + 精准过滤器定位 + 单一授权中心
✅ 推荐配置结构（Spring Security 5.7+ 兼容风格）
@Configuration
@EnableWebSecurity
public class SecurityConfig {
@Bean
public SecurityFilterChain filterChain(HttpSecurity http) throws Exception {
http
.csrf(csrf -> csrf.disable())
.headers(headers -> headers.frameOptions(FrameOptionsConfig::disable))
.requestCache(cache -> cache.requestCache(getHttpSessionRequestCache()))
.sessionManagement(session -> session
.sessionCreationPolicy(SessionCreationPolicy.IF_REQUIRED)
.maximumSessions(1)
)
// ⚠️ 关键：统一异常入口，避免各过滤器自行处理失败
.exceptionHandling(exceptions -> exceptions
.authenticationEntryPoint(new HttpStatusReturningEntryPoint(HttpStatus.UNAUTHORIZED))
)
// ✅ 所有 URL 授权规则集中在此处一次性声明
.authorizeHttpRequests(authz -> authz
.requestMatchers("/getrequest/**").authenticated()
.requestMatchers("/postrequest/**").authenticated()
.requestMatchers("/different-open-request/**").permitAll()
.anyRequest().authenticated()
);
// ✅ 使用 addFilterBefore/addFilterAfter 精确控制位置
// FilterA 专用于 GET，建议放在 BasicAuthenticationFilter 之前（避免基础认证干扰）
http.addFilterBefore(filterA(), BasicAuthenticationFilter.class);
// FilterB 专用于 POST，建议放在 UsernamePasswordAuthenticationFilter 之后（兼容表单登录流程）
http.addFilterAfter(filterB(), UsernamePasswordAuthenticationFilter.class);
return http.build();
}
@Bean
public FilterA filterA() {
FilterA filter = new FilterA();
filter.setCheckForPrincipalChanges(true);
filter.setAuthenticationManager(customBAuthenticationManager());
return filter;
}
@Bean
public FilterB filterB() {
FilterB filter = new FilterB();
filter.setCheckForPrincipalChanges(true);
// ✅ 使用全局 authenticationManager，确保 provider 一致
filter.setAuthenticationManager(authenticationManager());
return filter;
}
@Bean
public AuthenticationManager authenticationManager(
AuthenticationConfiguration config) throws Exception {
return config.getAuthenticationManager();
}
// 自定义 AuthenticationProvider 仍可注册，会被 global manager 自动委托
@Bean
public AuthenticationProvider customAauthProvider() {
DaoAuthenticationProvider provider = new DaoAuthenticationProvider();
provider.setUserDetailsService(userDetailsService());
provider.setPasswordEncoder(passwordEncoder());
return provider;
}
@Bean
public UserDetailsService userDetailsService() {
// your impl
}
@Bean
public PasswordEncoder passwordEncoder() {
return new BCryptPasswordEncoder();
}
}? 补充说明与最佳实践
- 不要手动调用 http.authenticationProvider(...) 多次：Spring Security 的 AuthenticationManagerBuilder 已自动聚合所有 @Bean AuthenticationProvider，显式调用易破坏委托链。
- 过滤器定位建议：
-
自定义 AuthenticationEntryPoint 示例（替代默认跳转）：
public class HttpStatusReturningEntryPoint implements AuthenticationEntryPoint { private final HttpStatus status; public HttpStatusReturningEntryPoint(HttpStatus status) { this.status = status; } @Override public void commence(HttpServletRequest req, HttpServletResponse res, AuthenticationException ex) throws IOException { res.setStatus(status.value()); res.getWriter().write("{\"error\":\"Unauthorized\"}"); } } - 调试技巧：启用 logging.level.org.springframework.security=DEBUG，观察 FilterChainProxy 日志中各过滤器是否被触发、SecurityContext 是否被正确设置。
? 总结：Spring Security 的过滤器链不是“并行开关”，而是有序责任链。务必保证：① 授权规则唯一且全覆盖；② 过滤器只负责“认证”，不越权做授权；③ 所有过滤器共享同一 AuthenticationManager；④ 异常统一由 AuthenticationEntryPoint 处理。遵循此原则，多场景差异化认证即可稳定运行。
