如何让 Spring Security 「少管闲事」_oauth2authenticationprocessingfilter-CSDN博客

本文讲述了在SpringSecurityOAuth2环境中，如何通过AOP实现对特定请求路径的OAuth2AuthenticationProcessingFilter的绕过，并探讨了如何调整自定义Filter与OAuth2Filter的执行顺序以优化权限处理。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

调用堆栈如下：

从调用的上下文可以看出（高亮那一行），执行逻辑在一个名为 OAuth2AuthenticationProcessingFilter 的 Filter 里，会尝试从请求中提取 Bearer Token，然后做一些处理（此处是 JWT 转换和校验等）。这个 Filter 是 ResourceServerSecurityConfigurer.configure 中初始化的，我们的应用同时也是作为一个 Spring Security OAuth2 Resource Server，从类名可以看出是对此的配置。

解决问题

找到了问题所在之后，经过自己的思考和同事间的讨论，得出了两种可行的解决方案。

方案一：让特定的请求跳过 OAuth2AuthenticationProcessingFilter

这个方案的思路是通过 AOP，在 OAuth2AuthenticationProcessingFilter.doFilter 方法执行前做个判断

如果请求路径是以 /custom/ 开头，就跳过该 Filter 继续往后执行；
如果请求路径非 /custom/ 开头，正常执行。

关键代码示意：

@Aspect

@Component

public class AuthorizationHeaderAspect {

@Pointcut(“execution(* org.springframework.security.oauth2.provider.authentication.OAuth2AuthenticationProcessingFilter.doFilter(…))”)

public void securityOauth2DoFilter() {}

@Around(“securityOauth2DoFilter()”)

public void skipNotCustom(ProceedingJoinPoint joinPoint) throws Throwable {

Object[] args = joinPoint.getArgs();

if (args == null || args.length != 3 || !(args[0] instanceof HttpServletRequest && args[1] instanceof javax.servlet.ServletResponse && args[2] instanceof FilterChain)) {

joinPoint.proceed();

return;

}

HttpServletRequest request = (HttpServletRequest) args[0];

if (request.getRequestURI().startsWith(“/custom/”)) {

joinPoint.proceed();

} else {

((FilterChain) args[2]).doFilter((ServletRequest) args[0], (ServletResponse) args[1]);

}

方案二：调整 Filter 顺序

如果能让请求先到达我们自定义的 Filter，请求路径以 /custom/ 开头的，处理完自定义 token 校验等逻辑，然后将 AuthorizationHeader 去掉（在 OAuth2AuthenticationProcessingFilter.doFilter 中，如果取不到 Bearer Token，不会抛异常），其它请求直接放行，也是一个可以达成目标的思路。

但现状是自定义的 Filter 默认是在 OAuth2AuthenticationProcessingFilter 后执行的，如何实现它们的执行顺序调整呢？

在我们前面找到的 OAuth2AuthenticationProcessingFilter 注册的地方，也就是 ResourceServerSecurityConfigurer.configure方法里，我们可以看到 Filter 是通过以下这种写法添加的：

@Override

public void configure(HttpSecurity http) throws Exception {

// … some code here

http

.authorizeRequests().expressionHandler(expressionHandler)

.and()

.addFilterBefore(resourcesServerFilter, AbstractPreAuthenticatedProcessingFilter.class)

.exceptionHandling()

.accessDeniedHandler(accessDeniedHandler)

.authenticationEntryPoint(authenticationEntryPoint);

}

核心方法是 HttpSecurity.addFilterBefore，说起 HttpSecurity，我们有印象啊……前面通过 WebSecurityConfigurerAdapter 来配置请求放行时入参是它，能否在那个时机将自定义 Filter 注册到 OAuth2AuthenticationProcessingFilter 之前呢？

我们将前面配置放行规则处的代码修改如下：

// …

httpSecurity.authorizeRequests().registry.regexMatchers(“^(?!/custom/).*$”).permitAll()

.and()

.addFilterAfter(new CustomWebFilter(), X509AuthenticationFilter.class);

// …

注： CustomWebFilter 改为直接 new 出来的，手动添加到 Security Filter Chain，不再自动注入到其它 Filter Chain。

为什么是将自定义 Filter 添加到 X509AuthenticationFilter.class 之后呢？可以参考 spring-security-config 包的 FilterComparator 里预置的 Filter 顺序来做决定，从前面的代码可知 OAuth2AuthenticationProcessingFilter 是添加到 AbstractPreAuthenticatedProcessingFilter.class 之前的，而在 FilterComparator 预置的顺序里，X509AuthenticationFilter.class 是在 AbstractPreAuthenticatedProcessingFilter.class 之前的，我们这样添加就足以确保自定义 Filter 在 OAuth2AuthenticationProcessingFilter 之前。

做了以上修改，自定义 Filter 已经在我们预期的位置了，那么我们在这个 Filter 里面，对请求路径以 /custom/ 开头的做必要处理，然后清空 Authorization Header 即可，关键代码示意如下：

@Override

public void doFilter(ServletRequest servletRequest, ServletResponse servletResponse, FilterChain filterChain) throws IOException, ServletException {

HttpServletRequest request = (HttpServletRequest) servletRequest;

if (request.getServletPath().startsWith(“/custom/”)) {

// do something here

// …

final String authorizationHeader = “Authorization”;

HttpServletRequestWrapper requestWrapper = new HttpServletRequestWrapper((HttpServletRequest) servletRequest) {

@Override

public String getHeader(String name) {

if (authorizationHeader.equalsIgnoreCase(name)) {