websecurityconfigureradapter 被彻底移除,因其继承式配置僵化,无法支持响应式安全与模块化;替代方案是函数式配置 securityfilterchain,并注意 passwordencoder、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$...),且PasswordEncoderBean 用的是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") 就永远不生效。










