SpringBoot整合SpringSecurity认证教程

本文深入解析了Spring Security 6+与Spring Boot 2.7/3.x升级后安全配置的范式变革——彻底告别僵化的WebSecurityConfigurerAdapter继承模式，转向灵活、模块化、响应式友好的函数式SecurityFilterChain配置；同时手把手厘清内存认证中PasswordEncoder缺失导致的空指针与凭据错误、数据库认证时JdbcUserDetailsManager因表结构/SQL/编码不匹配引发的静默失败，以及登录跳转异常、403拒绝访问和CSRF拦截等高频陷阱，覆盖从依赖引入、密码编码策略、路径匹配顺序到前后端协同的关键细节，助你避开新版本迁移中的所有“看似正常却死活跑不通”的坑。

为什么 WebSecurityConfigurerAdapter 被弃用了？

Spring Boot 2.7+ 和 Spring Security 6.0+ 彻底移除了 WebSecurityConfigurerAdapter，不是“不推荐”，是直接删了。继续用会编译失败，报 ClassNotFoundException 或 BeanCreationException。原因很实在：基于继承的配置方式太僵硬，无法支持响应式安全、细粒度 Bean 注入和模块化策略。

替代方案是函数式配置——用 @Bean 定义 SecurityFilterChain，配合 AuthenticationManagerBuilder（已淘汰）或独立构建 AuthenticationManager。

• 别再搜 “继承 WebSecurityConfigurerAdapter 示例”，那代码在新项目里根本跑不起来
• 如果用的是 Spring Boot 3.x，连 Servlet API 都默认不包含，必须显式加 spring-boot-starter-web
• http.authorizeHttpRequests() 是新 DSL 入口，旧的 authorizeRequests() 已不可用

内存认证怎么写才不踩空指针？

最简内存认证看似三行完事，但漏掉 UserDetailsService 或没配 PasswordEncoder，启动就抛 NullPointerException 或登录时提示 “Bad credentials” 却不告诉你哪错了。

关键点不在“怎么加用户”，而在“谁来校验密码”。Spring Security 6 默认要求非空 PasswordEncoder，哪怕你存的是明文，也得明确说 “我真要用 NoOpPasswordEncoder”。

• 用 PasswordEncoderFactories.createDelegatingPasswordEncoder() 是最稳妥的，它能自动识别 {noop}、{bcrypt} 等前缀
• 内存用户必须通过 User.withDefaultPasswordEncoder() 构建（仅限开发），否则密码不会被编码，校验必失败
• 别把 InMemoryUserDetailsManager 声明成 @Bean 后又在 SecurityFilterChain 里重复调 inMemoryAuthentication()，会冲突

@Bean
public UserDetailsService userDetailsService() {
    return new InMemoryUserDetailsManager(
        User.withUsername("admin")
            .password("{noop}123456") // 明文前缀必须写
            .authorities("READ", "WRITE")
            .build()
    );
}

数据库认证连不上 JdbcUserDetailsManager 怎么查？

JdbcUserDetailsManager 不是开箱即用的全自动组件。它只负责按固定 SQL 查库，字段名、表结构、密码编码方式全要对得上，错一个就静默失败——登录页没报错，但日志里全是 BadCredentialsException。

默认查的三张表：users（username, password, enabled）、authorities（username, authority）、group_authorities（可选）。如果你用的是 sys_user 这类自定义表名，必须重写 SQL。

• 检查 DataSource 是否已注入成功，@Autowired DataSource ds 打个断点确认不为 null
• 手动执行默认 SQL：SELECT password FROM users WHERE username = ?，看是否真能查到数据且 password 字段非空
• 如果密码是 bcrypt 编码，确保数据库里存的是完整哈希串（如 $2a$10$...），且 PasswordEncoder Bean 用的是 BCryptPasswordEncoder
• 别忘了给 JdbcUserDetailsManager 设置 setDataSource(ds)，它不会自动装配

为什么登录后跳转失效或 403？

常见现象：输入正确账号密码，页面刷一下又回到登录页；或者能进首页，但点个 /api/user 就 403。问题通常不在认证逻辑，而在授权规则没覆盖请求路径，或 CSRF 配置和前端不匹配。

Spring Security 6 默认开启 CSRF（针对表单 POST），而多数前端发 JSON 请求时没带 X-CSRF-TOKEN，结果所有 POST/PUT/DELETE 都被拦。另外，静态资源（/css/**、/js/**）若没显式放行，也会被当成受保护路径拦截。

• API 项目建议关掉 CSRF：http.csrf(csrf -> csrf.disable())，但前提是用了 token 认证（如 JWT）
• 放行静态资源必须写在 authorizeHttpRequests() 最前面，顺序错就无效：requestMatchers("/css/**", "/js/**").permitAll()
• 登录成功后默认跳转到上次被拦截的 URL，如果没记录（比如直接访问 login 页面），就会跳 /——确保根路径有对应 controller 或配置 defaultSuccessUrl("/home", true)

最常被忽略的一点：Spring Boot 的 spring.mvc.servlet.path 或自定义 DispatcherServlet 路径会影响 Security 的匹配前缀，比如设了 /api，那 requestMatchers("/user") 就永远不生效。

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