java后端基于过滤器或拦截器处理跨域请求

  工作中，与前端联调时经常会碰到跨域问题。指的是浏览器不能执行其他网站的脚本。它是由浏览器的同源策略造成的，是浏览器施加的安全限制。所以与客户端交互的时候就不会碰到这个问题。跨域问题，有多种解决方式，比如说前端进行代理，本文主要结合自己的实际开发，从服务器端的角度解决这个问题的。

    对于非简单请求(具体可以这篇文章，跨域资源共享)，在正式访问请求前，浏览器会发送一个预检请求，就是option请求。针对option请求，必须保证如下2点，后面的正式请求才会访问：第一，要能返回Access-Control-Allow-Origin 等字段，告诉浏览器你这个请求域名我服务端是可以支持的。第二，对于跨域的预检请求，要能返回成功。

ht我们一般使用servlet来处理http请求，开发中一般是子类继承httpservlet。option请求会到httpservlet的doOptions(HttpServletRequest req, HttpServletResponse resp)方法进行处理。     

 

httpservlet的doOption()方法

我们可以看到httpservlet的默认doOptions方法中，请求头中只加了一个"Allow",不满足我们说的第一个条件，option请求过不去，后面的请求也无法访问。所以我们要么子类重写doOptions方法，在方法里面解决，要么在进入这个方法前就解决跨域问题。接下来我会讲述2种不同的方式来解决这个问题。

 

---

1.基于java体系过滤器处理

我们可以使用过滤器fiter,http请求会在到达servlet的service(ServletRequest req, ServletResponse res)方法前被拦截。我们可以在doFilter方法中进行处理。

 

fiter处理跨域示例

注意：option请求，不会携带参数，和cookie信息，一般直接拦截掉，不进入后面的逻辑处理。 这种方式基于java本身体系，容易理解，也很方便，推荐使用这种模式。

 

---

2.基于spring体系的拦截器处理

在项目中，我们一般使用springmvc，可以使用拦截器Interceptor来处理跨域问题。                    springmvc只要靠DispatcherServlet这个类来处理http请求的。

 

 

DispaterServlet的doOptions方法

请求进到DispaterServlet的doOptions方法中，然后调用processRequest(request, response)方法处理请求逻辑，调用链比较长，最终会进入到doDispatcher方法。

 

 

DispaterServlet#doDispath()方法

这个方法处理逻辑也比较复杂，我们主要关注几点，找到请求对应的HandlerExecutionChain，这个mappedHandler包括对应的处理器和interceptor集合，然后找到对应的适配器，然后执行拦截器的prehandle()方法，我们需要在拦截器的prehandle()处理下跨域即可。

 

 

拦截器处理跨域示例

同样针对跨域请求，需要拦截掉，因为option不带参数，会对后面的业务逻辑有影像。

这种基于spring体系的拦截器处理跨域问题，需要对spring的源码有一定的理解，不然会出现问题，下面讲一下用这种方法踩过的坑。

1.之前有一个项目，我用拦截器这种方式怎么都不能解决跨域问题，百思不得其解，有的项目可以，有的项目用拦截器就不行，遂用过滤器的方法解决。后面阅读了一下源码才发现是spring的版本问题导致的。                                                                                                                          那个项目的spring是3.8版本的，之前的doOption()方法长这样。

 

 

3.8的版本doOptions()方法

我们可以看到，只有this.dispatchOptionsRequest为true的时候，才会进入到processRequest(request, response)方法，后面进行拦截器处理。但是this.dispatchOptionsReques默认为false，如果你不配置的话，后面的拦截器永远不会执行。会进入父类的doOptions()方法，前面讲过，原始的doOptions()方法无法处理跨域问题。如果要使用的话，需要到web.xml文件中配置一下

 

 

DispatcherServlet配置

spring4.0的版本后面优化这段逻辑，可以看下上面的那个截图，是基于spring4.2的，默认option请求，直接进入后面的逻辑。

2.前面讲过，doDisPatch()方法会去找对应的handler和拦截器，一般是通过requestmapping来查找，默认是根据url来查找

 

 

示例

这种情况下，会根据url,method联合查找处理器，因为我们这个请求是option请求，会报一个405异常，后面的请求会拦截掉了。解决办法，要么去掉method，在实际开发中，这个个人感觉没多大用，或者在method后面加一个OPTIONS。

原文地址：https://www.jianshu.com/p/12bcfd50cdcb