SpringSecurity认证环境搭建教程

本文深入解析了在Java中使用Spring Security 6（含Spring Boot 3.x）搭建认证环境时最易踩坑的核心要点：默认启用的CSRF防护机制如何导致403而非401、为何必须显式配置UserDetailsService而非依赖过时的内存用户、formLogin路径与处理URL错配引发的无限重定向、JWT场景下Bearer前缀缺失导致认证失效等关键问题，并给出开发调试与生产部署的不同应对策略——从临时禁用CSRF到正确集成X-CSRF-TOKEN，从明文密码占位符{noop}的必要性到Authorization头格式的毫厘之差，每一步配置都需严丝合缝，稍有疏忽即静默失败，堪称Spring Security实战避坑指南。

Spring Security 6 默认启用 CSRF，不关掉会 403

Spring Security 6+（含 Boot 3.x）默认开启 CSRF 防护，所有非 GET/HEAD/OPTIONS 请求都会校验 _csrf token。表单提交、AJAX POST、前端调用 /login 时若没带 token，直接返回 403 Forbidden，不是认证失败，而是 CSRF 拦截。

开发阶段快速验证可临时禁用：

@Configuration
@EnableWebSecurity
public class SecurityConfig {
    @Bean
    public SecurityFilterChain filterChain(HttpSecurity http) throws Exception {
        http
            .csrf(csrf -> csrf.disable()) // csrf.disable() 是关键
            .authorizeHttpRequests(auth -> auth
                .requestMatchers("/login", "/css/**", "/js/**").permitAll()
                .anyRequest().authenticated()
            )
            .formLogin(form -> form
                .loginPage("/login")
                .defaultSuccessUrl("/home")
            );
        return http.build();
    }
}

• 生产环境不能关 csrf.disable()，必须配合前端传递 X-CSRF-TOKEN 或渲染隐藏域
• csrf.disable() 只影响 CSRF，不影响认证流程本身
• 如果用 REST API + JWT，建议关掉 CSRF，但需确保认证头（如 Authorization: Bearer ...）已正确校验

用户名密码认证要配 UserDetailsService，不能只靠内存用户

Spring Security 不再自动创建内存用户（InMemoryUserDetailsManager 已不推荐），不显式配置 UserDetailsService，启动时会报错或登录永远 401 —— 因为没有用户源。

最简可用配置示例：

@Bean
public UserDetailsService userDetailsService() {
    UserDetails admin = User.withUsername("admin")
        .password("{noop}123456") // {noop} 表示明文，生产必须用 {bcrypt}
        .authorities("READ", "WRITE")
        .build();
    return new InMemoryUserDetailsManager(admin);
}

• {noop}123456 中的 {noop} 是密码编码器标识，漏写会抛 IllegalArgumentException: There is no PasswordEncoder mapped for the id "null"
• 数据库查用户时，必须返回 UserDetails 实现类，不能直接 return new User(...)；字段如密码为空或 null 会导致认证跳过
• 若用 JdbcUserDetailsManager，注意表结构必须符合默认 schema，否则要重写 usersByUsernameQuery

formLogin() 的路径和参数不匹配，登录永远跳回 login 页面

表单 action 提交到 /login，但 Spring Security 默认监听的是 /login POST，如果改了登录端点却没同步配置，请求就进不了认证过滤器链，直接被当成未授权请求重定向回登录页。

常见错配场景：

• 前端 form 写 action="/auth/login"，但没调用 formLogin().loginProcessingUrl("/auth/login")
• 用了自定义 UsernamePasswordAuthenticationFilter，但没 setFilterProcessesUrl，仍走默认 /login
• loginPage("/login") 和 loginProcessingUrl("/login") 必须区分：前者是 GET 展示页面，后者是 POST 处理认证

正确写法：

.formLogin(form -> form
    .loginPage("/login")                 // GET /login 返回登录页
    .loginProcessingUrl("/perform_login") // POST /perform_login 触发认证
    .defaultSuccessUrl("/dashboard", true)
)

JWT 认证要手动加 Bearer 前缀，否则 BearerTokenResolver 解不出 token

前端在 Authorization header 里只传 xxxxxx，Spring Security 的 BearerTokenResolver 默认只认 Bearer xxxxxx 格式，没前缀就当无效 token，直接放行或返回 401，不会进你的 JwtAuthenticationFilter。

• 检查前端是否写了 headers: { Authorization: "Bearer " + token }，漏空格或大小写错误（如 bearer）都失败
• 若想兼容无前缀，得自定义 BearerTokenResolver，重写 resolve 方法，但违背规范，不建议
• HttpSecurity.authorizeHttpRequests() 后必须显式放行 /login、/actuator/health 等非保护路径，否则 JWT 过滤器还没运行就被拦住

简单验证方式：curl 测试时别省略 Bearer ：

curl -H "Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9..." http://localhost:8080/api/data

实际跑通的关键不在“搭框架”，而在每个过滤器链节点是否真被触发、每条配置是否和请求路径/方法/头严格对齐。少一个 {noop}、多一个斜杠、漏一个 permitAll()，都会静默失败。

今天带大家了解了的相关知识，希望对你有所帮助；关于文章的技术知识我们会一点点深入介绍，欢迎大家关注golang学习网公众号，一起学习编程~