Spring WebFlux的/ping端点加入Spring Security白名单后仍需认证的问题

核心原因分析 #

1. 端点处理逻辑依赖认证上下文
   你的ping方法内部大概率在尝试从ReactiveSecurityContextHolder获取认证信息，但无认证时该上下文为空，导致方法抛出异常或返回错误响应——这不是Spring Security拦截的问题，而是业务处理逻辑的问题。当仅传递用户名（空密码）时，MyAuthenticationProvider通过了认证，SecurityContext中存在合法的Authentication对象，方法就能正常执行。

2. Security路径匹配的潜在疏漏
   虽然配置了pathMatchers("/ping")，但如果未明确指定请求方法，可能会误匹配其他HTTP方法的/ping请求（比如POST），不过这种情况概率较低，毕竟其他白名单端点正常。

3. 自定义认证提供者的逻辑漏洞
   你的MyAuthenticationProvider可能错误允许空密码的请求通过认证，而完全没有认证头时，Http Basic过滤器会触发默认401响应——但理论上permitAll应该跳过认证流程，所以需要结合认证提供者的代码排查。

解决方案 #

1. 修正ping方法的处理逻辑
   如果ping端点不需要认证信息，直接移除对认证上下文的依赖：

   public Mono<ServerResponse> ping(ServerRequest request) {
       return ServerResponse.ok()
               .contentType(MediaType.TEXT_PLAIN)
               .bodyValue("pong");
   }
   

   如果确实需要处理认证状态，添加空值兜底逻辑：

   public Mono<ServerResponse> ping(ServerRequest request) {
       return ReactiveSecurityContextHolder.getContext()
               .map(SecurityContext::getAuthentication)
               .defaultIfEmpty(null)
               .flatMap(auth -> {
                   String response = auth == null ? "ping (unauthenticated)" : "ping (authenticated as " + auth.getName() + ")";
                   return ServerResponse.ok()
                           .contentType(MediaType.TEXT_PLAIN)
                           .bodyValue(response);
               });
   }
   

2. 明确Security的路径匹配规则
   在pathMatchers中指定HTTP方法，避免模糊匹配：

   pathMatchers(HttpMethod.GET, "/ping")
   

3. 排查MyAuthenticationProvider的逻辑
   检查认证提供者对空密码、无认证信息的处理逻辑，确保permitAll的路径不会触发认证流程。比如确认当请求属于白名单时，Security不会调用认证提供者。

内容的提问来源于stack exchange，提问作者user8473984