什么是跨域 & 跨域的3种解决方案

所谓同源（即指在同一个域）就是两个页面具有相同的协议（protocol），主机（host）端口号（port）

同源策略是浏览器的一个安全功能，不同源的客户端脚本在没有明确授权的情况下，不能读写对方资源。同源策略是浏览器安全的基石

同源策略会阻止一个域的 javascript 脚本和另外一个域的内容进行交互。例如办公内外网环境，当我们访问外网一个恶意网站的时候，恶意网站就会利用我们的主机向内网的 url 发送 ajax 请求，破坏或盗取数据

浏览器的非同源限制以及3种解决思路

非同源限制

无法读取非同源网页的 Cookie、LocalStorage 和 IndexedDB
无法接触非同源网页的 DOM
无法向非同源地址发送 AJAX 请求，即 XHR 请求

跨域的解决思路 1 —— 避免非同源限制

让浏览器不做限制，指定参数，让浏览器不做校验，但该方法不太合理，因为它需要每个人都去做改动
不要发出 XHR 请求，这样就算是跨域，浏览器也不会有非同源限制，解决方案是 JSONP，通过动态创建一个 script，通过 script 发出请求

跨域的解决思路 2 —— 跨源资源共享方案

根据 W3C 的跨源资源共享方案，在被调用方修改代码，加上字段，告诉浏览器该网站支持跨域

跨域的解决思路 3 —— 隐藏跨域

使用 Nginx 反向代理，在 a 域名里面的的请求地址使用反向代理指向 b 域名，让浏览器以为一直在访问 a 网站，不触发跨域限制

JSONP

普通请求值 XHR，希望得到服务端返回的 content-type 一般是 json
JSONP 发出的是 script 请求，希望得到的返回是 js 脚本

Content-Type 是指 http/https 发送信息至服务端时的内容编码类型，在 HTTP 协议消息头中，使用 Content-Type 来表示请求和响应中的媒体类型信息。它用来告诉服务端如何处理请求的数据，以及告诉客户端（一般是浏览器）如何解析响应的数据，比如显示图片，解析并展示 html 等等。

并不是请求或响应独有的参数

JSONP 原理

以 JQuery 为例，发送 ajax 请求的时候，设置dataType:"jsonp"，将使用 JSONP 方式调用函数，函数的 url 变为myurl?callback=e5bbttt的形式，e5bbttt 就是一个临时方法名，后端会根据callback的值返回一个 js 脚本，如

<script>
    e5bbttt({"a":"aaa","b":"bbb"});
</script>

JQuery 会提前根据 ajax 中 success 的内容生成一个临时函数，名字就是 xxx

$.ajax({
    // 其他省略
    dataType:"jsonp",
    success:function(data){
        console.log(data.a);
        console.log(data.b);
    },
    jsonp:"e5bbttt"
})

// JQuery 生成的临时函数
function e5bbttt(data){
    ajaxObject.success(data);
}

服务端返回给客户端的e5bbttt({"a":"aaa","b":"bbb"});，相当于调用立即（？）调用了 JQuery 生成的e5bbttt函数，用完这个函数就销毁了（？）

JSONP 也算是一个约定俗成的“协议”，callback 是约定俗成的作为定义临时函数名的参数。如果想自定义这个参数名，需要在 ajax 中用 jsonp 属性定义。

JSONP 的弊端

需要服务器改动代码
只支持 GET 请求
发送的不是 xhr 请求
不安全

后端解决跨域

跟用户数据有关的就是动态请求，没有数据的是静态请求，比如 css js，so，HTTP 服务器（Apache、Nginx 等）至少做了两个作用

HTTP 服务器，处理静态请求
反向代理，负载均衡

在服务器端解决跨域有2种解决思路

在被调用后端应用解决：在响应头增加指定字段，告诉浏览器允许调用。这种解决方案的请求是直接从浏览器发送给后端服务器，在浏览器上会看到 b.com 的 url
在前端服务器解决：这是隐藏跨域的解决方案。这种跨域请求不是直接从浏览器发送的，而是从中间的 http 服务器（前端应用所在服务器）转发过去的，在浏览器中看到的还是 a.com 的 url，所以不会认为是跨域。但是该到 b.com 的请求还是会到 b.com

跨域原理及后端解决思路

依据浏览器同源策略，非同源脚本不可操作其他源下面的对象。想要操作其他源下的对象就需要跨域。综上所述，在同源策略的限制下，非同源的网站之间不能发送 ajax 请求。如有需要，可通过降域或其他技术实现。

为了解决浏览器跨域问题，W3C 提出了跨源资源共享方案，即 CORS(Cross-Origin Resource Sharing)。

CORS 可以在不破坏即有规则的情况下，通过后端服务器实现 CORS 接口，就可以实现跨域通信。

CORS 将请求分为两类：简单请求和非简单请求，分别对跨域通信提供了支持。

简单请求

在 CORS 出现前，发送 HTTP 请求时在头信息中不能包含任何自定义字段，且 HTTP 头信息不超过以下几个字段：
1. Accept
2. Accept-Language
3. Content-Language
4. Last-Event-ID
5. Content-Type 仅为这3种
  - application/x-www-form-urlencoded
  - multipart/form-data
  - text/plain
请求方法是 GET HEAD POST 且满足条件1

一个简单请求：

GET /test HTTP/1.1
Accept: */*
Accept-Encoding: gzip, deflate, sdch, br
Origin: http://www.test.com
Host: www.test.com

对于简单请求，CORS 的策略是请求时在请求头中增加一个 Origin 字段，表示请求发出的域。服务器收到请求后，根据该字段判断是否允许该请求访问。

如果允许，则在 HTTP 头信息中添加 Access-Control-Allow-Origin 字段，并返回正确的结果
如果不允许，则不添加 Access-Control-Allow-Origin 字段

除了上面提到的 Access-Control-Allow-Origin，还有几个字段用于描述 CORS 返回结果

Access-Control-Allow-Credentials：可选，用户是否可以发送、处理cookie
Access-Control-Expose-Headers：可选，可以让用户拿到的字段。有几个字段无论是否允许跨域都可以拿到的：Cache-Control、Content-Language、Content-Type、Expires、Last-Modified、Pragma

非简单请求

一般是发送 JSON 格式的 ajax 请求，或带有自定义头的请求

对于非简单请求的跨源请求，浏览器会在真实请求发出前，增加一次 OPTION 请求，称为预检请求(preflightrequest)。预检请求将真实请求的信息，包括请求方法、自定义头字段、源信息添加到 HTTP 头信息字段中，询问服务器是否允许这样的操作

例如一个 GET 请求的预检请求，包含一个自定义参数 X-Custom-Header

OPTIONS /test HTTP/1.1
Origin: http://www.test.com
Access-Control-Request-Method: GET // 请求使用的 HTTP 方法
Access-Control-Request-Headers: X-Custom-Header // 请求中包含的自定义头字段
Host: www.test.com

服务器收到请求时，需要分别对 Origin、Access-Control-Request-Method、Access-Control-Request-Headers 进行验证，验证通过后，会在返回 HTTP 头信息中添加：

HTTP/1.1 200 OK
Access-Control-Allow-Origin: http://www.test.com // 允许的域
Access-Control-Allow-Methods: GET, POST, PUT, DELETE // 允许的方法
Access-Control-Allow-Headers: X-Custom-Header // 允许的自定义字段
Access-Control-Allow-Credentials: true // 是否允许用户发送、处理 cookie
Access-Control-Max-Age: 172800 // 预检请求的有效期，单位为秒。有效期内，不需要发送预检请求，ps 48小时

当预检请求通过后，浏览器才会发送真实请求到服务器。这样就实现了跨域资源的请求访问。

所以后端处理其实处理的就是这次预检请求

注意：

在 Chrome 和 Firefox 中，如果 Access-Control-Allow-Methods 中并未允许 GET/POST/HEAD 请求，但允许跨域了，浏览器还是会允许 GET/POST/HEAD 这些简单请求访问，这时就必须在后台用其他办法禁掉这些 Method

后端应用处理 - Filter&HttpServletResponse 方法

这种方法不会用到 Spring，对 Servlet 也可以使用

在 web.xml 中配置

<!-- 跨域 -->
<filter>
    <filter-name>webFliter</filter-name>
    <filter-class>com.n031.filter.WebFliter</filter-class>
</filter>
<filter-mapping>
    <filter-name>webFliter</filter-name>
    <url-pattern>/*</url-pattern>
</filter-mapping>

编写 java 类

import javax.servlet.*;
import javax.servlet.http.HttpServletResponse;
import java.io.IOException;

public class WebFliter implements Filter {

    @Override
    public void init(FilterConfig filterConfig) throws ServletException {
    }

    @Override
    public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain)
            throws IOException, ServletException {
        HttpServletRequest req = (HttpServletRequest)request;
        HttpServletResponse res = (HttpServletResponse) response;
        // 允许跨域的域名，设置*表示允许所有域名
        String origin = req.getHeader("Origin");
        if ("abcdefg".contains(origin)) {  // 满足指定的条件
            res.addHeader("Access-Control-Allow-Origin", origin);
        }
        res.addHeader("Access-Control-Allow-Origin", "http://www.test.com");
        // 允许跨域的方法，可设置*表示所有
        res.addHeader("Access-Control-Allow-Methods", "GET, POST, PUT, DELETE");
        // 允许的自定义字段
        String headers = req.getHeader("Access-Control-Request-Headers"); // 获取 request 发来的自定义字段
        res.addHeader("Access-Control-Allow-Headers", headers);
        // 或者
        // res.addHeader("Access-Control-Allow-Headers", "X-Custom-Header");
        // 预检请求的有效期，单位为秒。有效期内，不需要发送预检请求，ps 48小时
        res.addHeader("Access-Control-Max-Age", "172800");
        // 还可以有其他配置...
        chain.doFilter(request, response);
    }

    @Override
    public void destroy() {
    }

}

后端应用处理 - Spring 方法

Spring 解决跨域的方法很多，感觉就和茴字有五种写法一样。这里列举的并不全。

先看下原理。~~说实话虽然搞不懂为什么这么做，但看了下这个类的源码确实是这么写的。~~

本质都是构造CorsConfiguration然后委托给DefaultCorsProcessor实现（责任链模式，要学的东西好多啊...）

public class CorsConfiguration {
    private List<String> allowedOrigins;
    private List<String> allowedMethods;
    private List<String> allowedHeaders;
    private List<String> exposedHeaders;
    private Boolean allowCredentials;
    private Long maxAge;
}

DefaultCorsProcessor的processRequest处理步骤如下（spring-web 5.1.8-RELEASE）

判断是否是包含 Origin 字段，不包含就放行，否则继续判断
判断 Response 的 Header 是否已经包含 Access-Control-Allow-Origin。如果包含，证明已经被处理过了，放行，否则继续判断
判断是否同源，如果是则放行，否则继续判断
到此步基本已经得出这是个跨域请求的结论。然后看配置了 CORS 规则
- 没有配置，且是预检请求，则拒绝该请求（说明该应用禁止跨域）
- 没有配置，且不是预检请求，跳过跨域处理（有可能导致返回数据被浏览器拦截）
- 配置了，则根据配置的规则（CorsConfiguration）决定是否放行

在 Controller 上添加 @CrossOrigin 注解

这种方式适合只有一两个 rest 接口需要跨域或者没有网关的情况下，这种处理方式就非常简单，适合在原来基代码基础上修改，影响比较小。

@CrossOrigin(allowCredentials = "true", allowedHeaders = "*", methods = {RequestMethod.GET, RequestMethod.POST, RequestMethod.DELETE}, origins = "*")
@PostMapping("/abc")
public String handler(@RequestBody String json) {
    return "abc";
}

增加 WebMvcConfigurer 全局配置

@Configuration
public class CorsConfig extends WebMvcConfigurerAdapter {

    @Override
    public void addCorsMappings(CorsRegistry registry) {
        registry.addMapping("/**")// 允许跨域的访问路径
            .allowedOrigins("*")// 允许跨域访问的源
            .allowedMethods("POST", "GET", "PUT", "OPTIONS", "DELETE")// 允许请求方法
            .maxAge(172800)// 预检间隔时间
            .allowCredentials(true);// 是否允许发送 cookie
    }
}

注意由于 Java8 开始支持 default method，这个类从 spring 5.0 开始已经过期，未来这个方法将转移到WebMvcConfigurer接口中

default void addCorsMappings(CorsRegistry registry){}

结合 Filter 使用

其实和方法2类似，都是构造CorsConfiguration

@Configuration
public class CorsConfig {
    @Bean
    public FilterRegistrationBean<CorsFilter> corsFilter() {
        UrlBasedCorsConfigurationSource source = new UrlBasedCorsConfigurationSource();

        CorsConfiguration config = new CorsConfiguration();
        // 是否发送cookie
        config.setAllowCredentials(true);
        // 允许的网站域名，全允许则设为 *
        config.addAllowedOrigin("http://localhost:8088");
        // 允许 HEADER 或 METHOD ， * 为全部
        config.addAllowedHeader("*");
        config.addAllowedMethod("*");
        source.registerCorsConfiguration("/**", config);
        FilterRegistrationBean<CorsFilter> bean = new FilterRegistrationBean<>(new CorsFilter(source));
        // 这个顺序很重要，为避免麻烦请设置在最前
        bean.setOrder(0);
        return bean;
    }
}

以上这种方案如果微服务多的话，需要在每个服务的主类上都加上这么段代码，增加了维护量。

这三种方案都是在 SpringBoot 的基础上实现的解决方案，在模块较多或者接口较多的情况下不易维护。

既然 Spring Cloud 自带 Gateway，下面就讲讲使用 Gateway 的跨域解决方案。（Gateway 是取代~~不断跳票的~~ Zuul 的新一代网关）

在 Gateway 增加 CorsFilter 拦截器

4 5 方法未验证

这种方案跟方案三有些类似，只不过是放到了 Gateway 端，对于有多个微服务模块的情况下，就大大减少了 SpringBoot 模块端的代码量，让各个模块更集中精力做业务逻辑实现。这个方案只需要在 Gateway 里添加 Filter 代码类即可。

import org.springframework.context.annotation.Configuration;
import org.springframework.http.HttpHeaders;
import org.springframework.http.HttpMethod;
import org.springframework.http.HttpStatus;
import org.springframework.http.server.reactive.ServerHttpRequest;
import org.springframework.http.server.reactive.ServerHttpResponse;
import org.springframework.web.cors.CorsUtils;
import org.springframework.web.server.ServerWebExchange;
import org.springframework.web.server.WebFilter;
import org.springframework.web.server.WebFilterChain;
import reactor.core.publisher.Mono;

import javax.servlet.http.HttpServletRequest;

@Configuration
public class CorsWebFilter implements WebFilter {

    private static final String ALL = "*";
    private static final String MAX_AGE = "18000";

    @Override
    public Mono<Void> filter(ServerWebExchange ctx, WebFilterChain chain) {
        ServerHttpRequest request = ctx.getRequest();
        String path = request.getPath().value();
        ServerHttpResponse response = ctx.getResponse();
        if ("/favicon.ico".equals(path)) {
            response.setStatusCode(HttpStatus.OK);
            return Mono.empty();
        }

        if (!CorsUtils.isCorsRequest((HttpServletRequest) request)) {
            return chain.filter(ctx);
        }

        HttpHeaders requestHeaders = request.getHeaders();
        HttpMethod requestMethod = requestHeaders.getAccessControlRequestMethod();
        HttpHeaders headers = response.getHeaders();
        headers.add(HttpHeaders.ACCESS_CONTROL_ALLOW_ORIGIN, requestHeaders.getOrigin());
        headers.addAll(HttpHeaders.ACCESS_CONTROL_ALLOW_HEADERS, requestHeaders.getAccessControlRequestHeaders());
        if (requestMethod != null) {
            headers.add(HttpHeaders.ACCESS_CONTROL_ALLOW_METHODS, requestMethod.name());
        }
        headers.add(HttpHeaders.ACCESS_CONTROL_ALLOW_CREDENTIALS, "true");
        headers.add(HttpHeaders.ACCESS_CONTROL_EXPOSE_HEADERS, ALL);
        headers.add(HttpHeaders.ACCESS_CONTROL_MAX_AGE, MAX_AGE);

        if (request.getMethod() == HttpMethod.OPTIONS) {
            response.setStatusCode(HttpStatus.OK);
            return Mono.empty();
        }
        return chain.filter(ctx);
    }
}

修改 Gateway 配置文件

在仔细阅读过 Gateway 的文档你就会发现，原来 CorsFilter 早已经在 Gateway 里了，不需要自己写代码实现，而且更灵活，修改配置文件即可，结合配置中心使用，可以实现动态修改。

spring:
  cloud:
    gateway:
      globalcors:
        corsConfigurations:
          '[/**]':
            allowedOrigins: "docs.spring.io"
            allowedMethods:
              - GET

后端服务器处理 - Ngnix 方法

这里的 Nginx 尽做反向代理功能，浏览器访问页面在 a.com 的 Nginx 上，ajax 请求接口是 b.com，所以浏览器认为是跨域

Nginx 在 nginx.conf 上配（vhost 是约定做法，这样做不修改主文件）

include vhost/*.config;

创建 cors.conf

server{
    listen 80; // 监听80端口
    server_name b.com; // 监听向 b.com 发送的请求
    location /{
        proxy_pass http://ser432ver.53253bb.com:8080; // 转发到哪里

        // Filter实现的功能在Nginx上再实现一遍

        add_header Access-Control-Allow-Origin $http_origin; // $http_ 可以获取请求中相应的 header 参数
        add_header Access-Control-Allow-Method *;
        add_header Access-Control-Allow-Headers X-Custom-Header;
        // 或者
        // add_header Access-Control-Allow-Headers $http_access_control_request_headers;
        add_header Access-Control-Allow-Credentials true;
        add_header Access-Max-age 172800;

        // 直接处理预检命令，if 后要带空格
        if ($request_method = OPTIONS) {
            return 200;
        }
    }
}

前端服务器解决跨域

但其实大部分情况下，我们会把前端应用和请求转发放在同一台 Nginx 上

server{
    listen 80; // 监听80端口
    server_name a.com; // 监听向 a.com 发送的请求

    location / {
        root   html;
        index  index.html index.htm;
    }

    locltion /ajaxserver {
        proxy_pass http://ser432ver.53253bb.com:8080; // 后端地址
    }
}

这样实质是隐藏跨域，让浏览器认为没有访问其他域就不会发生跨域。

前端代码需要在每个 ajax 请求前都要加上/ajaxserver

参考资料

ajax跨域完全讲解

https://www.imooc.com/learn/947

SpringBoot使用CORS解决跨域请求问题

https://www.cnblogs.com/7788IT/p/10693073.html

Spring MVC之@RequestParam @RequestBody @RequestHeader 等详解

https://blog.csdn.net/summerSunStart/article/details/78676781

你不知道的「跨域 CORS」

https://www.jianshu.com/p/abb5f6bf92c3

关于跨域问题和安全性的一点理解

https://blog.csdn.net/jaytalent/article/details/52213576

浅谈跨域威胁与安全

https://www.freebuf.com/articles/web/208672.html

cors跨域中关于access-control-allow-headers导致的错误

https://www.jianshu.com/p/cecb73b26a11

什么是跨域？跨域解决方法

https://blog.csdn.net/qq_38128179/article/details/84956552

Spring Cloud配置跨域访问的五种方案？你用的是哪一种呢？

https://segmentfault.com/a/1190000017188296

servlet跨域请求

https://blog.csdn.net/qq_34135615/article/details/82900786

跨域(CORS) 解决方案中，为什么 Access-Control-Allow-Methods 不起作用？

https://segmentfault.com/q/1010000005067552/a-1020000005067822

posted @ 2019-11-10 05:52 n031 阅读(12841) 评论(0) 编辑收藏举报

刷新页面返回顶部

Loading

鶸