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

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添加头文件。
https://docs.spring.io/spring/docs/4.2.0.release/spring-framework-reference/html

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

<mvc:cors>
    <mvc:mapping path="/**" />
</mvc:cors>

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

再一次测试发现，并没有解决问题，还是和原先的效果是一样的。说明通过配置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
出处：