繁体   English   中英

Spring Boot WebMvcTest 返回 302 而不是 GET 方法的 401

[英]Spring Boot WebMvcTest returns 302 instead of 401 for GET methods

我有一个带有 REST 端点的应用程序,这些端点通过JWT身份验证(外部资源服务器)进行保护。 在将我的项目从 spring-boot 2.2.7 升级到 2.4.3 之后,一些WebMvcTest集成测试失败了。 具体来说,没有JWT令牌的GET请求的测试用例 - 以前它们将返回401 UNAUTHORIZED UNAUTHORIZED ,现在它们返回302 REDIRECThttp://localhost/oauth2/authorization/keycloak

@Test
void shouldNotAllowAccessForUnauthenticatedUsers() throws Exception {
    // given
    var params = createParams();

    // when / then
    mockMvc.perform(get(MY_URI)
            .params(params)
            .contentType(MediaType.APPLICATION_JSON)
            .content(new byte[0]))
            .andExpect(status().isUnauthorized());
}

没有自定义 web 安全配置被导入,只是@WebMvcTest@AutoConfigureMockMvc加上相关@ContextConfiguration和映射器 bean 的 @ContextConfiguration。

没有身份验证的测试中的POST方法返回403 (与升级之前一样)。 此问题仅在测试中出现 - 当应用程序运行时,调用任何没有令牌的端点都会导致401

有没有办法将WebMvcTest配置为返回401而不是302

Andy Wilkinson 的问题启发了我深入研究这个问题,因为没有真正将 Keycloak 适配器添加为显式依赖项(只有spring-boot-starter-securityspring-boot-starter-oauth2-clientspring-boot-starter-oauth2-resource-server ),但这里的配置中提到了keycloak

  security:
    oauth2:
      resourceserver:
        jwt:
          issuer-uri: ...
      client:
        registration:
          keycloak:
            client-id: ...
            client-secret: ...
            authorization-grant-type: ...
            scope: ...
        provider:
          keycloak:
            authorization-uri: ...
            token-uri: ...

对应用程序端点的请求使用来自 issuer-uri 的 JWT 令牌进行身份验证,但 HTTP 客户端对其他服务的调用使用 Keycloak 中的客户端注册进行身份验证(用于服务到服务身份验证)。

无论如何,我相信升级后的这种行为变化是由于Spring Boot 2.3中引入的一个功能,特别是:“ @WebMvcTest中的 OAuth2 参数绑定”。 OAuth2 的自动配置现在包含在@WebMvcTest中,这导致此测试尝试使用客户端配置(在运行时仅用于服务到服务)重定向到 keycloak。

我通过注释测试 class 解决了这个问题:

@ImportAutoConfiguration(exclude = {OAuth2ClientAutoConfiguration.class, OAuth2ResourceServerAutoConfiguration.class})

(资源服务器配置也必须被排除在外,才能正确处理模拟的 JWT。)

也许有人会觉得这很有帮助。

暂无
暂无

声明:本站的技术帖子网页,遵循CC BY-SA 4.0协议,如果您需要转载,请注明本站网址或者原文地址。任何问题请咨询:yoyou2525@163.com.

 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM