1. 问题背景：测试中遇到的 403 错误
在 Spring Boot 应用中，当使用 Spring Security 进行权限控制时，开发者在编写控制器层的集成测试时，可能会遇到 HTTP 状态码 403 Forbidden 的错误。即使测试方法使用了 @WithMockUser 注解来模拟具有特定角色的用户，请求仍然被拒绝。这通常是由于安全配置与测试用例之间的不匹配或理解偏差导致的。
例如，以下是一个典型的 WebSecurityConfig 配置片段，它要求所有请求都必须由 ADMIN 角色用户访问：
@Configuration
@EnableWebSecurity
class WebSecurityConfig(
private val jwtAuthenticationConverter: JwtAuthenticationConverter
) {
@Bean
fun filterChain(http: HttpSecurity): SecurityFilterChain {
http
.cors().and()
.csrf().disable() // 禁用 CSRF
.authorizeRequests()
.anyRequest().hasRole("ADMIN") // 要求所有请求拥有 ADMIN 角色
.and()
.oauth2ResourceServer().jwt().jwtAuthenticationConverter(jwtAuthenticationConverter)
return http.build()
}
}对应的测试代码尝试模拟一个 ADMIN 角色用户访问接口：
@Test
@WithMockUser(roles = ["ADMIN"]) // 模拟 ADMIN 角色用户
fun `testA`() {
mvc
.perform(
post("/bla/bla")
.contentType(MediaType.APPLICATION_JSON)
).andExpect(status().isCreated) // 期望 201 Created
}尽管 @WithMockUser(roles = ["ADMIN"]) 似乎提供了所需的权限，测试仍然返回 403 错误。
2. 403 错误原因分析
Spring Security 中的 403 错误表明用户已被认证（或尝试认证），但没有足够的权限访问请求的资源。在这种情况下，尽管使用了 @WithMockUser(roles = ["ADMIN"])，但仍有几种可能导致 403 错误的原因：
- 安全配置过于严格： anyRequest().hasRole("ADMIN") 意味着任何请求都必须通过 ADMIN 角色验证。在测试环境中，如果配置没有被适当调整，即使模拟了用户，也可能因为其他未预料到的安全过滤器链问题而失败。
- 角色/权限匹配问题： Spring Security 在处理 hasRole() 和 hasAuthority() 时，默认情况下 hasRole("ADMIN") 会在内部查找名为 ROLE_ADMIN 的权限（authority）。如果 @WithMockUser 提供的角色没有正确映射到安全配置期望的权限，就会导致权限不足。
- 其他安全过滤器干扰： 虽然 csrf().disable() 禁用了 CSRF 保护，排除了 CSRF 导致 403 的可能性，但其他自定义的过滤器或 OAuth2 配置也可能在测试环境中产生副作用。
3. 解决方案
针对上述问题，可以采取以下两种主要策略来解决测试中的 403 错误。
3.1 方案一：为测试环境临时放宽安全限制
最直接的方法是在测试时临时放宽安全配置，允许所有请求通过，这样可以将测试重点放在控制器逻辑本身，而不是安全配置。
修改 WebSecurityConfig (仅限测试配置或使用 @Profile):
在测试配置中，可以将 anyRequest().hasRole("ADMIN") 更改为 anyRequest().permitAll()。这通常通过 Spring 的 @Profile 注解或专门的测试配置类来实现，以确保这种宽松的配置不会影响生产环境。
@Configuration
@EnableWebSecurity
// 可以在测试配置中，使用 @Profile("test") 来区分生产和测试环境的配置
// @Profile("test")
class TestWebSecurityConfig(
private val jwtAuthenticationConverter: JwtAuthenticationConverter
) {
@Bean
fun filterChain(http: HttpSecurity): SecurityFilterChain {
http
.cors().and()
.csrf().disable()
.authorizeRequests()
.anyRequest().permitAll() // 允许所有请求通过，仅用于测试
.and()
.oauth2ResourceServer().jwt().jwtAuthenticationConverter(jwtAuthenticationConverter)
return http.build()
}
}注意事项：
- 仅限测试： permitAll() 极大地降低了安全性，绝不能在生产环境中使用。务必通过 Spring Profile 或独立的测试配置类来隔离此设置。
- 测试范围： 这种方法适用于测试控制器逻辑，而不适用于测试安全配置本身。如果需要测试权限控制是否正确，应使用方案二。
3.2 方案二：确保角色与权限的精确匹配
如果希望在测试中也验证权限控制，就需要确保 @WithMockUser 提供的角色与 WebSecurityConfig 中 hasRole() 或 hasAuthority() 期望的权限完全匹配。
Spring Security 默认情况下，hasRole("ADMIN") 会检查用户是否拥有 ROLE_ADMIN 权限。因此，@WithMockUser 应该提供 ROLE_ADMIN 作为权限，或者确保 roles 属性能够正确映射。
方法 A: 使用 authorities 属性明确指定权限
推荐使用 authorities 属性，因为它更明确，直接对应 Spring Security 内部的权限概念。
@Test
@WithMockUser(authorities = ["ROLE_ADMIN"]) // 明确指定权限为 ROLE_ADMIN
fun `testA`() {
mvc
.perform(
post("/bla/bla")
.contentType(MediaType.APPLICATION_JSON)
).andExpect(status().isCreated)
}方法 B: 确认 roles 属性的映射行为
@WithMockUser 的 roles 属性会自动为提供的角色名添加 ROLE_ 前缀。因此，@WithMockUser(roles = ["ADMIN"]) 等同于为用户添加了 ROLE_ADMIN 权限。如果你的 WebSecurityConfig 使用 hasRole("ADMIN")，那么 roles = ["ADMIN"] 应该是正确的。
如果在使用 roles = ["ADMIN"] 后仍然遇到 403，则需要检查：
- Spring Security 版本： 不同版本的 Spring Security 可能在角色处理上有细微差别。
- 自定义 GrantedAuthority 实现： 如果有自定义的 GrantedAuthority 实现，确保它能正确解析和匹配权限。
- OAuth2 Resource Server 配置： 检查 jwtAuthenticationConverter 是否正确地将 JWT 中的声明转换为 Spring Security 的 GrantedAuthority 列表。确保转换后的权限包含 ROLE_ADMIN。
调试技巧： 在测试中，可以通过添加 andDo(print()) 来打印完整的请求和响应信息，这有助于诊断 403 错误的具体原因：
import static org.springframework.test.web.servlet.result.MockMvcResultHandlers.print;
// ...
@Test
@WithMockUser(roles = ["ADMIN"])
fun `testA`() {
mvc
.perform(
post("/bla/bla")
.contentType(MediaType.APPLICATION_JSON)
)
.andDo(print()) // 打印请求和响应详情
.andExpect(status().isCreated)
}通过查看 print() 输出中的响应头和响应体，可以获取更多关于 403 错误的详细信息，例如是否有特定的安全过滤器拒绝了请求。
4. 总结
在 Spring Boot 测试中解决 403 错误，关键在于理解 Spring Security 的工作原理以及测试环境中安全配置的交互。当遇到此类问题时，首先考虑是临时放宽安全限制以测试核心业务逻辑，还是需要精确匹配角色与权限以验证安全机制。对于后者，明确使用 authorities = ["ROLE_ADMIN"] 通常是更健壮的选择，同时结合调试工具能够帮助快速定位并解决问题。始终记住，测试环境的安全配置应与生产环境严格区分，以避免潜在的安全风险。
