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
出处:http://www.cnblogs.com/wxw16/p/10674539.html

posted @ 2019-04-09 00:34  wuxiwei  阅读(1460)  评论(1编辑  收藏  举报