SpringMVC跨域问题排查以及源码实现

最近一次项目中，将SpringMVC版本从4.1.1升级到4.3.10，出现跨域失败的情况。关于同源策略和跨域解决方案，网上有很多资料。

项目采用的方式是通过实现过滤器Filter，在Response返回头文件添加跨域资源共享（CORS） 相关的参数。

response.addHeader("Access-Control-Allow-Origin", "http://test.com");response.addHeader("Access-Control-Allow-Credentials", "true");response.addHeader("Access-Control-Allow-Methods", "POST, GET, OPTIONS, DELETE, PUT, HEAD");response.addHeader("Access-Control-Allow-Headers", "Content-Type");response.addHeader("Access-Control-Max-Age", "3600");

发布完成，回归测试的过程发现跨域失败，但是本地开发是没有问题的。

经过排查线下和线上的区别，因为是前后端分离项目，所以线上基本会配置前端和后端独立的域名，通过跨域的方式调用。但是本地开发的时候，前端通过nginx配置转发请求到后端服务，也就避开了跨域的问题。所以为了不影响线上环境，先暂时把线上的调用改成和线下一致，服务正常。

后面开始排查具体的失败问题，开始排查的几个点：

1. 4.1.1到4.3.10 SpringMVC有什么版本更新
2. 为什么4.1.1没有问题，4.3.10会有问题，毕竟项目采用的跨域解决方案是比较通用（W3C标准 ）的，没有涉及框架层面。

通过查看SpringMVC官方文档，从4.2.0版本开始，SpringMVC开始支持CORS跨域解决方案，主要表现是通过简单的配置，就可以支持CORS，从后面源码分析，可以看到本质还是对Response添加头文件。

可以看到最快的方式实现CORS，通过xml配置

把项目代码原先的跨域方式改成，框架提供的方案。（去掉原先的过滤器）

再一次测试发现，并没有解决问题，还是和原先的效果是一样的。说明通过配置xml的实现和原先的实现几乎是一样的。继续排查问题。

可以看到跨域预处理请求返回状态码是302，考虑到几点：3xx一般是权限问题导致、跨域预处理请求头参数不会携带参数。所以联想到Login的拦截器，通过Debug打断点的方式，确实options请求走到了拦截器里面，那也就基本确认是因为拦截器校验失败，导致的跨域预处理请求失败。后面验证了之前4.1.1的校验过程，看到options请求并没有走到Login的拦截器。

通过上面的排查，也就有了后面的问题和源码解读。

1. 为什么4.1.1和4.3.10的options请求拦截器处理不一样。
2. 4.2.0以上版本SpringMVC对于CORS的实现原理。

SpringMVC的入口文件DispatcherServlet，我们分为4.2.0之前和之前两个方面追溯options请求的处理过程，对于SpringMVC本身源码不详细讨论，只针对跨域相关内容。

4.2.0之前，默认情况下DispatcherServlet继承自FrameworkServlet，FrameworkServlet处理了所有的http请求，调用processRequest() 方法。我们主要看下options请求。

protected void doOptions(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {    if(this.dispatchOptionsRequest) {        this.processRequest(request, response);        if(response.containsHeader("Allow")) {            return;        }    }    super.doOptions(request, new HttpServletResponseWrapper(response) {        public void setHeader(String name, String value) {            if("Allow".equals(name)) {                value = (StringUtils.hasLength(value)?value + ", ":"") + RequestMethod.PATCH.name();            }            super.setHeader(name, value);        }    });}

SpringMVC提供了Boolean类型的dispatchOptionsRequest来控制是否开启对options请求的处理，默认情况下不做处理，直接调用父类的doOptions()方法。基本上没有做任何处理，就对请求返回正常的响应结果，主要是CORS预请求作为校验需要的请求头封装。

显然在4.2.0之前的版本，options请求不会进入到Login拦截器。

4.2.0之后，SpringMVC源码文件加入了很多关于CORS处理的文件，我们还是先看到FrameworkServlet对于options的请求处理。

protected void doOptions(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {    if(this.dispatchOptionsRequest || CorsUtils.isPreFlightRequest(request)) {        this.processRequest(request, response);        if(response.containsHeader("Allow")) {            return;        }    }    super.doOptions(request, new HttpServletResponseWrapper(response) {        public void setHeader(String name, String value) {            if("Allow".equals(name)) {                value = (StringUtils.hasLength(value)?value + ", ":"") + HttpMethod.PATCH.name();            }            super.setHeader(name, value);        }    });}

可以看到最大的区别是CorsUtils.isPreFlightRequest(request)，这个静态方法是用于判断请求是否是预处理请求，显然options会返回true，所以也就会执行和其他请求一样的processRequest()方法，继续往下看。

快速查看调用路径FrameworkServlet.processRequest()->DispatcherServlet.doService()->DispatcherServlet.doDispatch()。

try {    processedRequest = this.checkMultipart(request);    multipartRequestParsed = processedRequest != request;    mappedHandler = this.getHandler(processedRequest);    if(mappedHandler == null || mappedHandler.getHandler() == null) {        this.noHandlerFound(processedRequest, response);        return;    }    HandlerAdapter ha = this.getHandlerAdapter(mappedHandler.getHandler());    String method = request.getMethod();    boolean isGet = "GET".equals(method);    if(isGet || "HEAD".equals(method)) {        long lastModified = ha.getLastModified(request, mappedHandler.getHandler());        if(this.logger.isDebugEnabled()) {            this.logger.debug("Last-Modified value for [" + getRequestUri(request) + "] is: " + lastModified);        }        if((new ServletWebRequest(request, response)).checkNotModified(lastModified) && isGet) {            return;        }    }    if(!mappedHandler.applyPreHandle(processedRequest, response)) {        return;    }    mv = ha.handle(processedRequest, response, mappedHandler.getHandler());    if(asyncManager.isConcurrentHandlingStarted()) {        return;    }    this.applyDefaultViewName(processedRequest, mv);    mappedHandler.applyPostHandle(processedRequest, response, mv);} catch (Exception var20) {    dispatchException = var20;} catch (Throwable var21) {    dispatchException = new NestedServletException("Handler dispatch failed", var21);}

可以看到一个请求，会通过getHandler()方法获取处理器，在处理之前会先执行applyPreHandle()，处理所有拦截器的前置方法，所以我们可以确定的一个问题是，因为doOptions()的不同，所以options请求拦截器处理不一样。

继续看CORS的实现原理，我们看下getHandler()方法的实现。

protected HandlerExecutionChain getHandler(HttpServletRequest request) throws Exception {    Iterator var2 = this.handlerMappings.iterator();    HandlerExecutionChain handler;    do {        if(!var2.hasNext()) {            return null;        }        HandlerMapping hm = (HandlerMapping)var2.next();        if(this.logger.isTraceEnabled()) {            this.logger.trace("Testing handler map [" + hm + "] in DispatcherServlet with name '" + this.getServletName() + "'");        }        handler = hm.getHandler(request);    } while(handler == null);    return handler;}

针对请求request，在handlerMappings这个Map中相应的处理器，在SpringMVC执行init方法时，已经预加载处理器Map。处理器实现了HandlerMapping接口的getHandler方法。看到默认AbstractHandlerMapping抽象类实现了该方法。

public final HandlerExecutionChain getHandler(HttpServletRequest request) throws Exception {    Object handler = this.getHandlerInternal(request);    if(handler == null) {        handler = this.getDefaultHandler();    }    if(handler == null) {        return null;    } else {        if(handler instanceof String) {            String handlerName = (String)handler;            handler = this.getApplicationContext().getBean(handlerName);        }        HandlerExecutionChain executionChain = this.getHandlerExecutionChain(handler, request);        if(CorsUtils.isCorsRequest(request)) {            CorsConfiguration globalConfig = this.corsConfigSource.getCorsConfiguration(request);            CorsConfiguration handlerConfig = this.getCorsConfiguration(handler, request);            CorsConfiguration config = globalConfig != null?globalConfig.combine(handlerConfig):handlerConfig;            executionChain = this.getCorsHandlerExecutionChain(request, executionChain, config);        }        return executionChain;    }}

我们主要看对于CORS的处理代码段，首先判断CORS请求。然后是对CORS配置的config处理（也就是SpringMVC提供的配置接口，包括xml、注释），主要是支持请求类型、域、缓存时长等，继续看getCorsHandlerExecutionChain()实现。

protected HandlerExecutionChain getCorsHandlerExecutionChain(HttpServletRequest request, HandlerExecutionChain chain, CorsConfiguration config) {    if(CorsUtils.isPreFlightRequest(request)) {        HandlerInterceptor[] interceptors = chain.getInterceptors();        chain = new HandlerExecutionChain(new AbstractHandlerMapping.PreFlightHandler(config), interceptors);    } else {        chain.addInterceptor(new AbstractHandlerMapping.CorsInterceptor(config));    }    return chain;}

对于CORS的非简单请求，主要分为预处理请求和正常请求，SpringMVC分别进行处理，把针对每个请求的处理看作是调用链，这个调用链肯定会包含拦截器，看到上面对于预处理请求的处理方式，会把调用链根据config配置重新初始化，同时把拦截器赋值进去，这样就更近一步说明，options预处理请求，会执行到Login拦截器中。针对CORS的正常请求，SpringMVC就会动态添加一个拦截器，它的主要作用就是和我们自己实现的过滤器的效果是一致的。

综上，基本知道问题发生的原因和原理，项目后面的改进方式，采用对Login拦截器，使用封装的CorsUtils.isPreFlightRequest(request)判断是不是预处理请求，如果是，就不对登录态校验。

后记：对于options的请求，为什么SpringMVC4.2.0以后，需要配置config处理，而不是直接和原先的处理一样，直接返回成功。猜测是可以通过config更丰富的配置。而不是笼统的返回跨域支持和不支持。

转载请注明出处。

作者：wuxiwei

出处：