自定义AbstractAuthenticationProcessingFilter在SecurityFilterChain中的放置位置确认

Spring Security的过滤器链有固定执行顺序，自定义AbstractAuthenticationProcessingFilter的放置位置并非随意，核心要遵循认证逻辑的执行时机与依赖关系，以下是明确规则和经验：

明确放置规则 #

• 必须放在SecurityContextPersistenceFilter之后：该过滤器负责从会话/请求中加载SecurityContext，自定义认证过滤器需要依赖它来将认证后的Authentication存入上下文，否则认证结果无法被后续过滤器识别。
• 必须放在FilterSecurityInterceptor之前：这是过滤器链中负责权限校验的最后一环，认证必须在权限校验完成前完成，否则权限校验时SecurityContext无有效认证信息，请求会被拦截。
• 启用CSRF时，需放在CsrfFilter之后：如果你的认证请求是POST/PUT等修改型请求，会触发CSRF校验，放在CsrfFilter之后可避免请求被提前拦截（若你的认证路径不需要CSRF，可单独配置放行）。

经验法则（根据认证场景调整） #

• 平行认证场景：如果你的过滤器是处理新的认证方式（如短信验证码、API密钥），与用户名密码认证平行，可放在UsernamePasswordAuthenticationFilter的位置前后，甚至用addFilterAt替换它（若无需保留用户名密码认证）。
• 前置认证场景：如果需要先通过自定义认证（如API密钥校验），再执行后续认证逻辑，需放在UsernamePasswordAuthenticationFilter之前。
• 参考默认过滤器顺序：启动Spring应用时，日志会输出"Security filter chain"的完整过滤器列表及顺序，可对照确认你的过滤器插入位置是否合理。

修正后的示例配置 #

注意：原示例中SecurityFilterChain的Bean定义有误，正确写法如下：

@Bean
public SecurityFilterChain securityFilterChain(HttpSecurity http) throws Exception {
    MyAuthenticationProcessingFilter customAuthFilter = new MyAuthenticationProcessingFilter();
    // 必须注入AuthenticationManager，否则过滤器无法处理认证逻辑
    customAuthFilter.setAuthenticationManager(http.getSharedObject(AuthenticationManager.class));
    
    http
        // 示例：放在SecurityContextPersistenceFilter之后，确保能操作SecurityContext
        .addFilterAfter(customAuthFilter, SecurityContextPersistenceFilter.class)
        .authorizeHttpRequests(auth -> auth
            .anyRequest().authenticated()
        );
    
    return http.build();
}

内容的提问来源于stack exchange，提问作者Jason