关于java:如何让-Spring-Security-少管闲事

记两种让 Spring Security「少管闲事」的办法。

遇到问题

一个利用对外提供 Rest 接口，接口的拜访认证通过 Spring Security OAuth2 管制，token 模式为 JWT。因为一些起因，某一特定门路前缀（假如为 /custom/）的接口须要应用另外一种自定义的认证形式，token 是一串无规则的随机字符串。两种认证形式的 token 都是在 Headers 里传递，模式都是 Authorization: bearer xxx。

所以当内部申请这个利用的接口时，状况示意如下：

这时，问题呈现了。

我通过 WebSecurityConfigurerAdapter 配置 Spring Security 将 /custom/ 前缀的申请间接放行：

httpSecurity.authorizeRequests().regexMatchers("^(?!/custom/).*$").permitAll();

但申请 /custom/ 前缀的接口依然被拦挡，报了如下谬误：

{
  "error": "invalid_token",
  "error_description": "Cannot convert access token to JSON"
}

剖析问题

从谬误提醒首先能够通过查看排除掉 CustomWebFilter 的嫌疑，自定义认证形式的 token 不是 JSON 格局，它外面天然也不然尝试去将其转换成 JSON。

那揣测问题出在 Spring Security「多管闲事」，拦挡了不该拦挡的申请上。

通过一番面向搜寻编程和源码调试，找到抛出以上错误信息的地位是在 JwtAccessTokenConverter.decode 办法里：

protected Map<String, Object> decode(String token) {
    try {
        // 上面这行会抛出异样
        Jwt jwt = JwtHelper.decodeAndVerify(token, verifier);
        // ... some code here
    }
    catch (Exception e) {throw new InvalidTokenException("Cannot convert access token to JSON", e);
    }
}

调用堆栈如下：

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

解决问题

找到了问题所在之后，通过本人的思考和共事间的探讨，得出了两种可行的解决方案。

计划一：让特定的申请跳过 OAuth2AuthenticationProcessingFilter

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

1. 如果申请门路是以 /custom/ 结尾，就跳过该 Filter 持续往后执行；
2. 如果申请门路非 /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 校验等逻辑，而后将 Authorization Header 去掉（在 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)) {return null;}
                return super.getHeader(name);
            }

            @Override
            public Enumeration<String> getHeaders(String name) {if (authorizationHeader.equalsIgnoreCase(name)) {return new Vector<String>().elements();}
                return super.getHeaders(name);
            }
        };
        filterChain.doFilter(requestWrapper, servletResponse);
    } else {filterChain.doFilter(servletRequest, servletResponse);
    }
}

小结

通过尝试，两种计划都能满足需要，我的项目里最终应用了计划一，置信也还有其它的思路能够解决问题。

通过这一过程，也暴露出了对 Spring Security 的了解不够的问题，后续须要抽空做一些更深刻的学习。

参考

• https://www.cnblogs.com/alala…