jsonp与cors跨域的一些理解（转）

CORS（跨域资源共享，Cross-Origin Resource Sharing）
CORS其实出现时间不短了，它在*上的定义是：跨域资源共享（CORS ）是一种网络浏览器的技术规范，它为Web服务器定义了一种方式，允许网页从不同的域访问其资源。而这种访问是被同源策略所禁止的。
CORS系统定义了一种浏览器和服务器交互的方式来确定是否允许跨域请求。 它是一个妥协，有更大的灵活性，但比起简单地允许所有这些的要求来说更加安全。

比如，
站点 http://domain-a.com 的某 HTML 页面通过 <img> 的 src 请求 http://domain-b.com/image.jpg。
网络上的许多页面都会加载来自不同域的CSS样式表，图像和脚本等资源。

出于安全考虑，浏览器会限制从脚本内发起的跨域HTTP请求。
例如，XMLHttpRequest 和 Fetch 遵循同源策略。
因此，使用 XMLHttpRequest或 Fetch 的Web应用程序只能将HTTP请求发送到其自己的域。
为了改进Web应用程序，开发人员要求浏览器厂商允许跨域请求。

https://developer.mozilla.org/zh-CN/docs/Web/HTTP/Access_control_CORS

同源策略， 即JavaScript只能访问同域下的内容

Same-origin policy
From Wikipedia, the free encyclopedia

In computing, the same-origin policy is an important concept in the web application security model.
Under the policy, a web browser permits scripts contained in a first web page to access data in a second web page, but only if both web pages have the same origin.
An origin is defined as a combination of URI scheme, hostname, and port number.
This policy prevents a malicious script on one page from obtaining access to sensitive data on another web page through that page's Document Object Model.

https://en.wikipedia.org/wiki/Same-origin_policy

而W3C的官方文档目前还是工作草案，但是正在朝着W3C推荐的方向前进。

简言之，CORS就是为了让AJAX可以实现可控的跨域访问而生的。

浏览器的同源策略，即是浏览器之间要隔离不同域的内容，禁止互相操作。

比如，当你打开了多个网站，如果允许多个网站之间互相操作，那么其中一个木马网站就可以通过这种互相操作进行一系列的非法行为，获取你在各个网站的相关信息，很明显这是不安全的，所以同源策略避免了很多这样的问题。

但是同时也带来了一些问题，比如有时候你想通过自己的网站去获取另一个自己的网站的一些资料信息，但是由于两者域名不同，所以就被同源策略隔离了，那么这个时候就需要了解一下浏览器的跨域问题。

跨域常见的两种方式，分别是jsonp和新推出的cors，即cross-origin resourse sharing，其实这货出现的时间也不短了，只是我现在才注意到而已。

先说说jsonp，先说个简单的例子再讲百度的例子。

我们有个www.a.com的页面

<script type="text/javascript"
src="http://www.b.com?name=qiangzi"></script>
<script type="text/javascript">
function jsonp(json){
    alert(json[‘age’]);
}
</script>

这是请求 http://www.b.com?name=qiangzi 返回的js文件。

jsonp({'name':'qiangzi','age':20});

事先声明，个人没有实际的使用过jsonp去进行跨域操作，所以所有的分析都是猜想，若有不对请指出。

我们来试着去分析上面的代码，a页面事先写好了一个回调函数，即是供我们请求回的js回调的函数，这里的回调函数式alert参数组中的年龄。

我们再看我们的请求，首先我们的请求是写在script标签里面的，所以说明正常来说我们请求回来的内容应该是一段js文件。接着看，我们发现请求的时候同时传了一个参数过去name="qiangzi"，所以我们基本可以猜测在www.b.com服务器那边，接收到a页面的请求，同时接收到传过来的name数据，根据这个数据进行相应的查询，找到了{name:"qiangzi",age:20}这样的一段数据之后，我们的b服务器于是就构造了一段这样的js文件传给请求的页面

jsonp({'name':'qiangzi','age':20});

也就是在原页面输出我们请求的name对应的年龄。很明显，我们请求的script标签中的src不能写死，而应该是一个动态的插入name值的过程。

从前台写好回调函数，到根据请求的参数值构造请求链接，跨域服务器根据链接进行相应处理返回数据并执行回调函数，这整一个过程就是jsonp的过程，当然上述只是我个人猜想，毕竟没有去实现过，所以有错望大神们指出。

那么我们按照这个思路再来看看百度搜索下拉框的jsonp跨域操作。

我们在百度搜索框输入jsonp，马上出现了下拉框，分别有jsonp json jsonp跨域等等，其实这一过程就是使用到了jsonp跨域处理，具体怎么过跨法，我们打开F12，找到network这里可以看到这样的一个请求

也就是这个链接

https://sp0.baidu.com/5a1Fazu8AA54nxGko9WTAnF6hhy/su?wd=jsonp&json=1&p=3&sid=19637_18286_1442_17711_18240_17944_19568_19806_19558_19808_19843_19861_17001_15825_12254&req=2&bs=xmlhttprequest&pbs=jsonp&csor=5&pwd=json&cb=jQuery1102032008872299992563_1463242088002&_=1463242088035

点击我们可以看到这样的一段东西

那么这样的一段东西其实是什么呢？其实这就是我们jsonp跨域请求回来的数据以及调用的函数。

接下来就按照我们刚才的思路分析下整个过程。

首先，百度在前台写好了一个回调函数，即是接收跨域返回来的数据并且出现下拉框，把数据填充到下拉框中。当我们在百度搜索的输入框（注意区分开此处的输入框和上句话中的下拉框）输入我们要搜索的内容时，此时百度页面马上获取我们输入的值，并构造请求，即我们上文中提到的

https://sp0.baidu.com/5a1Fazu8AA54nxGko9WTAnF6hhy/su?wd=jsonp&json=1&p=3&sid=19637_18286_1442_17711_18240_17944_19568_19806_19558_19808_19843_19861_17001_15825_12254&req=2&bs=xmlhttprequest&pbs=jsonp&csor=5&pwd=json&cb=jQuery1102032008872299992563_1463242088002&_=1463242088035

对于这一段请求，我个人看着都觉得有点怕怕的，所以为了方便理解jsonp我们简化下应该可以这样理解

https://sp0.baidu.com/su?wd=jsonp

服务器查询jsonp对应的联想关键词，并把这些关键词填充在一个数组中，然后把这个数组作为参数调用前台写好的回调函数，返回这段js文件给前台，然后我们就看到了在搜索框输入jsonp然后下拉框出现一系列关键词的功能。

至此，关于jsonp的例子讲诉差不多结束。那么jsonp有哪些优缺点呢？

jsonp的优点是兼容所有的浏览器，无论是主流的还是以前的。而它的缺点则是由于jsonp发起的请求是get方式的，即参数是填充在请求地址上，所以这种方式发送的数据有限制。

关于jsonp再补充点内容，其实不知道大家有没有想过，我们使用的很多API接口，调用他们返回的数据，其实这一过程就是跨域了，因为我们请求的是别的站点的数据，不做跨域处理我们是不可能获得信息的，只是有时候我们是按着API说明文档照写的所以忽视了这个

我这里有个国外的API，根据填写的邮编搜索邮编所对应的位置信息

http://www.geonames.org/postalCodeLookupJSON?postalcode=10504&country=US&callback=?

在这个API中我们需要填写三个参数，一个是邮编号码，另一个是对应的国家，而第三个就是我们的回调函数。

这个是该API接口返回的数据

整个API调用的过程就是，我们在前台写好一个callback函数，这个callback函数的功能就是根据我们的需求而写，然后在构造请求的时候把这个callback函数的名称写在请求对应的callback上。至于其他的邮编号码国家这些当然也是在我们前台页面构造的。构造完这些请求之后，当我们发起请求的时候，API服务器端就会根据我们的请求信息，拿到相应的数据，并把这些数据放到我们写的回调函数对应的参数中传回来，并进行调用，整个API调用完毕。

说完了jsonp，接下来说说cors跨域这玩意。

在前文看到同源策略的时候，不知道大家有没有想过，难道就不能让两个跨域的站点写一个秘密的协议，达成一种交易从而使得两者可以进行跨域操作获取数据之类的吗？嗯，我个人觉得cors做的就是这件事。

关于cors在*上的定义是这样的：跨域资源共享（CORS ）是一种网络浏览器的技术规范，它为Web服务器定义了一种方式，允许网页从不同的域访问其资源。而这种访问是被同源策略所禁止的。CORS系统定义了一种浏览器和服务器交互的方式来确定是否允许跨域请求。它是一个妥协，有更大的灵活性，但比起简单地允许所有这些的要求来说更加安全。

要想实现cors跨域，需要做的就是两件事，一个是我们的浏览器要支持cors跨域这一操作（主流谷歌和火狐均支持，ie版本要高于ie10才行），另外，我们的服务器端必须要设置好Access-Control-Allow-Origin从而支持跨域操作。

cors相对于jsonp而言的好处就是支持所有的请求方式，不止是get请求，还支持post,put请求等等，而它的缺点就很明显，无法兼容所有的浏览器，对于要兼容到老式浏览器而言，还是使用jsonp好点。

http://www.cnblogs.com/jelly7723/p/5494330.html

序言：跨域资源共享向来都是热门的需求，使用CORS可以帮助我们快速实现跨域访问，只需在服务端进行授权即可，无需在前端添加额外设置，比传统的JSONP跨域更安全和便捷。

一、基本介绍

简单来说，CORS是一种访问机制，英文全称是Cross-Origin Resource Sharing，即我们常说的跨域资源共享，通过在服务器端设置响应头，把发起跨域的原始域名添加到Access-Control-Allow-Origin 即可。

1. CORS工作原理

CORS实现跨域访问并不是一蹴而就的，需要借助浏览器的支持，从原理题图我们可以清楚看到，简单的请求（通常指GET/POST/HEAD方式，并没有去增加额外的请求头信息）直接创建了跨域请求的XHR对象，而复杂的请求则要求先发送一个”预检”请求，待服务器批准后才能真正发起跨域访问请求。

根据官方文档W3C规范-CORS 的描述，目前CORS使用了如下头部信息：

注：请求头信息由浏览器检测到跨域自动添加，无需过多干预，重点放在Response headers，它可以帮助我们在服务器进行跨域授权，例如允许哪些原始域可放行，是否需要携带Cookie信息等。

2. Request Headers（请求头）

• Origin

  表示跨域请求的原始域。

• Access-Control-Request-Method

  表示跨域请求的方式。（如GET/POST）

• Access-Control-Request-Headers

  表示跨域请求的请求头信息。

3. Response headers（响应头 ）

• Access-Control-Allow-Origin

  表示允许哪些原始域进行跨域访问。（字符数组）

• Access-Control-Allow-Credentials

  表示是否允许客户端获取用户凭据。（布尔类型）
  使用场景：例如现在从浏览器发起跨域请求，并且要附带Cookie信息给服务器。则必须具备两个条件：1. 浏览器端：发送AJAX请求前需设置通信对象XHR的withCredentials 属性为true。 2.服务器端：设置Access-Control-Allow-Credentials为true。两个条件缺一不可，否则即使服务器同意发送Cookie，浏览器也无法获取。正确姿势如下：

• Access-Control-Allow-Methods

  表示跨域请求的方式的允许范围。（例如只授权GET/POST）

• Access-Control-Allow-Headers

  表示跨域请求的头部的允许范围。

• Access-Control-Expose-Headers

  表示暴露哪些头部信息，并提供给客户端。（因为基于安全考虑，如果没有设置额外的暴露，跨域的通信对象XMLHttpRequest只能获取标准的头部信息）

• Access-Control-Max-Age

  表示预检请求 [Preflight Request] 的最大缓存时间。

二、CORS实现跨域访问

授权方式

• 方式1：返回新的CorsFilter
• 方式2：重写WebMvcConfigurer
• 方式3：使用注解（@CrossOrigin）
• 方式4：手工设置响应头（HttpServletResponse ）

注：CorsFilter / WebMvcConfigurer / @CrossOrigin 需要SpringMVC 4.2 以上的版本才支持，对应SpringBoot 1.3 版本以上都支持这些CORS特性。不过，使用SpringMVC4.2 以下版本的小伙伴也不用慌，直接使用方式4通过手工添加响应头来授权CORS跨域访问也是可以的。附：在SpringBoot 1.2.8 + SpringMVC 4.1.9 亲测成功。

注：方式1和方式2属于全局CORS配置，方式3和方式4属于局部CORS配置。如果使用了局部跨域是会覆盖全局跨域的规则，所以可以通过@CrossOrigin注解来进行细粒度更高的跨域资源控制。

1. 返回新的CorsFilter（全局跨域）

在任意配置类，返回一个新的CorsFilter Bean，并添加映射路径和具体的CORS配置信息。

package com.hehe.yyweb.config;

@Configuration
public class GlobalCorsConfig {
    @Bean
    public CorsFilter corsFilter() {
        //1.添加CORS配置信息
        CorsConfiguration config = new CorsConfiguration();
          //放行哪些原始域
          config.addAllowedOrigin("*");
          //是否发送Cookie信息
          config.setAllowCredentials(true);
          //放行哪些原始域(请求方式)
          config.addAllowedMethod("*");
          //放行哪些原始域(头部信息)
          config.addAllowedHeader("*");
          //暴露哪些头部信息（因为跨域访问默认不能获取全部头部信息）
          config.addExposedHeader("*");

        //2.添加映射路径
        UrlBasedCorsConfigurationSource configSource = new UrlBasedCorsConfigurationSource();
        configSource.registerCorsConfiguration("/**", config);

        //3.返回新的CorsFilter.
        return new CorsFilter(configSource);
    }
}

2. 重写WebMvcConfigurer（全局跨域）

在任意配置类，返回一个新的WebMvcConfigurer Bean，并重写其提供的跨域请求处理的接口，目的是添加映射路径和具体的CORS配置信息。

package com.hehe.yyweb.config;

@Configuration
public class GlobalCorsConfig {
    @Bean
    public WebMvcConfigurer corsConfigurer() {
        return new WebMvcConfigurer() {
            @Override
            //重写父类提供的跨域请求处理的接口
            public void addCorsMappings(CorsRegistry registry) {
                //添加映射路径
                registry.addMapping("/**")
                        //放行哪些原始域
                        .allowedOrigins("*")
                        //是否发送Cookie信息
                        .allowCredentials(true)
                        //放行哪些原始域(请求方式)
                        .allowedMethods("GET","POST", "PUT", "DELETE")
                        //放行哪些原始域(头部信息)
                        .allowedHeaders("*")
                        //暴露哪些头部信息（因为跨域访问默认不能获取全部头部信息）
                        .exposedHeaders("Header1", "Header2");
            }
        };
    }
}

3. 使用注解（局部跨域）

在方法上（@RequestMapping）使用注解 @CrossOrigin ：

    @RequestMapping("/hello")
    @ResponseBody
    @CrossOrigin("http://localhost:8080")
    public String index( ){
        return "Hello World";
    }

或者在控制器（@Controller）上使用注解 @CrossOrigin ：

@Controller
@CrossOrigin(origins = "http://xx-domain.com", maxAge = 3600)
public class AccountController {

    @RequestMapping("/hello")
    @ResponseBody
    public String index( ){
        return "Hello World";
    }
}

4. 手工设置响应头（局部跨域 ）

使用HttpServletResponse对象添加响应头（Access-Control-Allow-Origin）来授权原始域，这里Origin的值也可以设置为”*” ，表示全部放行。

    @RequestMapping("/hello")
    @ResponseBody
    public String index(HttpServletResponse response){
        response.addHeader("Access-Control-Allow-Origin", "http://localhost:8080");
        return "Hello World";
    }

三、测试跨域访问

首先使用Spring Initializr快速构建一个Maven工程，什么都不用改，在static目录下，添加一个页面：index.html 来模拟跨域访问。目标地址: http://localhost:8090/hello

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8"/>
    <title>Page Index</title>
</head>
<body>
<h2>前台系统</h2>
<p id="info"></p>
</body>
<script src="webjars/jquery/3.2.1/jquery.js"></script>
<script>
    $.ajax({
        url: 'http://localhost:8090/hello',
        type: "POST",
        success: function (data) {
            $("#info").html("跨域访问成功:"+data);
        },
        error: function (data) {
            $("#info").html("跨域失败!!");
        }
    })
</script>
</html>

然后创建另一个工程，在Root Package添加Config目录并创建配置类来开启全局CORS。

@Configuration
public class GlobalCorsConfig {

    @Bean
    public WebMvcConfigurer corsConfigurer() {
        return new WebMvcConfigurer() {
            @Override
            public void addCorsMappings(CorsRegistry registry) {
                registry.addMapping("/**");
            }
        };
    }
}

接着，简单编写一个Rest接口 ，并指定应用端口为8090。

@SpringBootApplication
@RestController
public class YyWebApplication {

    @Bean
    public TomcatServletWebServerFactory tomcat() {
        TomcatServletWebServerFactory tomcatFactory = new TomcatServletWebServerFactory();
        tomcatFactory.setPort(8090); //默认启动8090端口
        return tomcatFactory;
    }

    @RequestMapping("/hello")
    public String index() {
        return "Hello World";
    }

    public static void main(String[] args) {
        SpringApplication.run(YyWebApplication.class, args);
    }
}

最后分别启动两个应用，然后在浏览器访问：http://localhost:8080/index.html ，可以正常接收JSON数据，说明跨域访问成功！！

尝试把全局CORS关闭，或者没有单独在方法或类上授权跨域，再次访问：http://localhost:8080/index.html 时会看到跨域请求失败！！

四、源码和文档

Github源码：SpringBoot-Cross-Orgin

专题地址：SpringBoot 从入门到上瘾

规范文档：W3C规范-CORS

传统文档：SpringMVC-CORS 使用手册

推荐阅读：跨域资源共享 CORS 详解 - 阮一峰

http://www.spring4all.com/article/177

概述

• CORS能做什么：

     正常使用AJAX会需要正常考虑跨域问题，所以伟大的程序员们又折腾出了一系列跨域问题的解决方案，如JSONP、flash、ifame、xhr2等等。

     本文介绍的CORS就是一套AJAX跨域问题的解决方案。

 

• CORS的原理：

     CORS定义一种跨域访问的机制，可以让AJAX实现跨域访问。CORS 允许一个域上的网络应用向另一个域提交跨域 AJAX 请求。实现此功能非常简单，只需由服务器发送一个响应标头即可。

 

• CORS浏览器支持情况如下图：

       

     

　　喜闻乐见、普大喜奔的支持情况，尤其是在移动终端上，除了opera Mini；

　　PC上的现代浏览器都能友好的支持，除了IE9-，不过前端工程师对这种情况早应该习惯了...

     

 

CORS启航

 

　　假设我们页面或者应用已在 http://www.test1.com 上了，而我们打算从 http://www.test2.com 请求提取数据。一般情况下，如果我们直接使用 AJAX 来请求将会失败，浏览器也会返回“源不匹配”的错误，"跨域"也就以此由来。

　　利用 CORS，http://www.test2.com 只需添加一个标头，就可以允许来自 http://www.test1.com 的请求，下图是我在PHP中的 hander() 设置，“*”号表示允许任何域向我们的服务端提交请求：

     

　　也可以设置指定的域名，如域名 http://www.test2.com ，那么就允许来自这个域名的请求：

     

     

　　当前我设置的header为“*”，任意一个请求过来之后服务端我们都可以进行处理&响应，那么在调试工具中可以看到其头信息设置，其中见红框中有一项信息是“Access-Control-Allow-Origin：* ”，表示我们已经启用CORS，如下图。

　　PS：由于demo都在我厂的两台测试机间完成，外网也不能访问，所以在这就不提供demo了，见谅

     

 　　简单的一个header设置，一个支持跨域&POST请求的server就完成了:)

 

　　当然，如果没有开启CORS必定失败的啦，如下图：

　　

问题&小结

• 刚刚说到的兼容性。CORS是W3C中一项较新的方案，所以部分浏览器还没有对其进行支持或者完美支持，详情可移至 http://www.w3.org/TR/cors/
• 安全问题。CORS提供了一种跨域请求方案，但没有为安全访问提供足够的保障机制，如果你需要信息的绝对安全，不要依赖CORS当中的权限制度，应当使用更多其它的措施来保障，比如OAuth2。

 

　　自认为的cors使用场景：

• cors在移动终端支持的不错，可以考虑在移动端全面尝试；PC上有不兼容和没有完美支持，所以小心踩坑。当然浏览器兼容就是个伪命题，说不准某个浏览器的某个版本就完美兼容了，说不准就有点小坑，尼玛伤不起！～
• jsonp是get形式，承载的信息量有限，所以信息量较大时CORS是不二选择；
• 配合新的JSAPI(fileapi、xhr2等)一起使用，实现强大的新体验功能。

http://www.cnblogs.com/Darren_code/p/cors.html

一，简单跨域（不带头 不带参数）
要在servlet的doget或者dopost里增加返回头
resp.addHeader("Access-Control-Allow-Origin",
"http://zhucetest.duapp.com"); 如果是公共的则返回*即可。
二，复杂跨域
浏览器会先发起一个验证的网络连接到servlet的 doOptions 在doOptions里返回
resp.addHeader("Access-Control-Allow-Origin",
"http://zhucetest.duapp.com");
resp.addHeader("Access-Control-Allow-Methods","GET,POST,OPTIONS");
resp.addHeader("Access-Control-Allow-Headers", "Content-type,hello");

resp.addHeader("Access-Control-Max-Age", "50");即可
三，post传参 加这句话
xmlHttp.setRequestHeader("Content-Type", "application/x-www-form-urlencoded");
四，get传参 直接加在url里
五，servelet接受参数
直接调用req.getparams...

http://yunshangbuhe.iteye.com/blog/1979587

本文概述了跨域资源共享机制及其所涉及的 HTTP 首部字段。

概述EDIT

跨域资源共享标准新增了一组 HTTP 首部字段，允许服务器声明哪些源站有权限访问哪些资源。另外，规范要求，对那些可能对服务器数据产生副作用的 HTTP 请求方法（特别是 GET 以外的 HTTP 请求，或者搭配某些 MIME 类型的 POST 请求），浏览器必须首先使用 OPTIONS 方法发起一个预检请求（preflight request），从而获知服务端是否允许该跨域请求。服务器确认允许之后，才发起实际的 HTTP 请求。在预检请求的返回中，服务器端也可以通知客户端，是否需要携带身份凭证（包括 Cookies和 HTTP 认证相关数据）。

接下来的内容将讨论相关场景，并剖析该机制所涉及的 HTTP 首部字段。

若干访问控制场景EDIT

这里，我们使用三个场景来解释跨域资源共享机制的工作原理。这些例子都使用 XMLHttpRequest 对象。

本文中的 JavaScript 代码片段都可以从 http://arunranga.com/examples/access-control/ 获得。另外，使用支持跨域  XMLHttpRequest 的浏览器访问该地址，可以看到代码的实际运行结果。

关于服务端对跨域资源共享的支持的讨论，请参见这篇文章： Server-Side_Access_Control (CORS)。

简单请求

某些请求不会触发 CORS 预检请求。本文称这样的请求为“简单请求”，请注意，该术语并不属于 Fetch （其中定义了 CORS）规范。若请求满足所有下述条件，则该请求可视为“简单请求”：

• 使用下列方法之一：
  • GET
  • HEAD
  • POST
• Fetch 规范定义了对 CORS 安全的首部字段集合，不得人为设置该集合之外的其他首部字段。该集合为：
  • Accept
  • Accept-Language
  • Content-Language
  • Content-Type （需要注意额外的限制）
  • DPR
  • Downlink
  • Save-Data
  • Viewport-Width
  • Width
• Content-Type 的值属于下列之一：
  • application/x-www-form-urlencoded
  • multipart/form-data
  • text/plain

注意: 这些跨域请求与浏览器发出的其他跨域请求并无二致。如果服务器未返回正确的响应首部，则请求方不会收到任何数据。因此，那些不允许跨域请求的网站无需为这一新的 HTTP 访问控制特性担心。

注意: WebKit Nightly 和 Safari Technology Preview 为Accept, Accept-Language, 和 Content-Language 首部字段的值添加了额外的限制。如果这些首部字段的值是“非标准”的，WebKit/Safari 就不会将这些请求视为“简单请求”。WebKit/Safari 并没有在文档中列出哪些值是“非标准”的，不过我们可以在这里找到相关讨论：Require preflight for non-standard CORS-safelisted request headers Accept, Accept-Language, and Content-Language, Allow commas in Accept, Accept-Language, and Content-Language request headers for simple CORS, and Switch to a blacklist model for restricted Accept headers in simple CORS requests。其它浏览器并不支持这些额外的限制，因为它们不属于规范的一部分。

比如说，假如站点 http://foo.example 的网页应用想要访问 http://bar.other 的资源。http://foo.example 的网页中可能包含类似于下面的 JavaScript 代码：

var invocation = new XMLHttpRequest();
var url = 'http://bar.other/resources/public-data/';

function callOtherDomain() {
  if(invocation) {
    invocation.open('GET', url, true);
    invocation.onreadystatechange = handler;
    invocation.send();
  }
}

客户端和服务器之间使用 CORS 首部字段来处理跨域权限：

分别检视请求报文和响应报文：

GET /resources/public-data/ HTTP/1.1
Host: bar.other
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3pre) Gecko/ Minefield/.1b3pre
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Connection: keep-alive
Referer: http://foo.example/examples/access-control/simpleXSInvocation.html
Origin: http://foo.example

HTTP/1.1 200 OK
Date: Mon, 01 Dec 2008 00:23:53 GMT
Server: Apache/2.0.61
Access-Control-Allow-Origin: *
Keep-Alive: timeout=2, max=100
Connection: Keep-Alive
Transfer-Encoding: chunked
Content-Type: application/xml

第 1~10 行是请求首部。第10行 的请求首部字段 Origin 表明该请求来源于 http://foo.exmaple。

第 13~22 行是来自于 http://bar.other 的服务端响应。
响应中携带了响应首部字段 Access-Control-Allow-Origin（第 16 行）。
使用 Origin 和 Access-Control-Allow-Origin 就能完成最简单的访问控制。
本例中，服务端返回的 Access-Control-Allow-Origin: * 表明，该资源可以被任意外域访问。
如果服务端仅允许来自 http://foo.example 的访问，该首部字段的内容如下：

Access-Control-Allow-Origin: http://foo.example

现在，除了 http://foo.example，其它外域均不能访问该资源（该策略由请求首部中的 ORIGIN 字段定义，见第10行）。
Access-Control-Allow-Origin 应当为 * 或者包含由 Origin 首部字段所指明的域名。

预检请求

与前述简单请求不同，“需预检的请求”要求必须首先使用 OPTIONS   方法发起一个预检请求到服务器，以获知服务器是否允许该实际请求。"预检请求“的使用，可以避免跨域请求对服务器的用户数据产生未预期的影响。

当请求满足下述任一条件时，即应首先发送预检请求：

• 使用了下面任一 HTTP 方法：
  • PUT
  • DELETE
  • CONNECT
  • OPTIONS
  • TRACE
  • PATCH
• 人为设置了对 CORS 安全的首部字段集合之外的其他首部字段。该集合为：
  • Accept
  • Accept-Language
  • Content-Language
  • Content-Type (but note the additional requirements below)
  • DPR
  • Downlink
  • Save-Data
  • Viewport-Width
  • Width
• Content-Type 的值不属于下列之一:
  • application/x-www-form-urlencoded
  • multipart/form-data
  • text/plain

注意: WebKit Nightly 和 Safari Technology Preview 为Accept, Accept-Language, 和 Content-Language 首部字段的值添加了额外的限制。如果这些首部字段的值是“非标准”的，WebKit/Safari 就不会将这些请求视为“简单请求”。WebKit/Safari 并没有在文档中列出哪些值是“非标准”的，不过我们可以在这里找到相关讨论：Require preflight for non-standard CORS-safelisted request headers Accept, Accept-Language, and Content-Language, Allow commas in Accept, Accept-Language, and Content-Language request headers for simple CORS, and Switch to a blacklist model for restricted Accept headers in simple CORS requests。其它浏览器并不支持这些额外的限制，因为它们不属于规范的一部分。

如下是一个需要执行预检请求的 HTTP 请求：

var invocation = new XMLHttpRequest();
var url = 'http://bar.other/resources/post-here/';
var body = '<?xml version="1.0"?><person><name>Arun</name></person>';

function callOtherDomain(){
  if(invocation)
    {
      invocation.open('POST', url, true);
      invocation.setRequestHeader('X-PINGOTHER', 'pingpong');
      invocation.setRequestHeader('Content-Type', 'application/xml');
      invocation.onreadystatechange = handler;
      invocation.send(body);
    }
}

上面的代码使用 POST 请求发送一个 XML 文档，该请求包含了一个自定义的请求首部字段（X-PINGOTHER: pingpong）。另外，该请求的 Content-Type 为 application/xml。因此，该请求需要首先发起“预检请求”。

OPTIONS /resources/post-here/ HTTP/1.1
Host: bar.other
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3pre) Gecko/20081130 Minefield/3.1b3pre
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Connection: keep-alive
Origin: http://foo.example
Access-Control-Request-Method: POST
Access-Control-Request-Headers: X-PINGOTHER, Content-Type

HTTP/1.1 200 OK
Date: Mon, 01 Dec 2008 01:15:39 GMT
Server: Apache/2.0.61 (Unix)
Access-Control-Allow-Origin: http://foo.example
Access-Control-Allow-Methods: POST, GET, OPTIONS
Access-Control-Allow-Headers: X-PINGOTHER, Content-Type
Access-Control-Max-Age: 86400
Vary: Accept-Encoding, Origin
Content-Encoding: gzip
Content-Length: 0
Keep-Alive: timeout=2, max=100
Connection: Keep-Alive
Content-Type: text/plain

预检请求完成之后，发送实际请求：

POST /resources/post-here/ HTTP/1.1
Host: bar.other
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3pre) Gecko/20081130 Minefield/3.1b3pre
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Connection: keep-alive
X-PINGOTHER: pingpong
Content-Type: text/xml; charset=UTF-8
Referer: http://foo.example/examples/preflightInvocation.html
Content-Length: 55
Origin: http://foo.example
Pragma: no-cache
Cache-Control: no-cache

<?xml version="1.0"?><person><name>Arun</name></person>

HTTP/1.1 200 OK
Date: Mon, 01 Dec 2008 01:15:40 GMT
Server: Apache/2.0.61 (Unix)
Access-Control-Allow-Origin: http://foo.example
Vary: Accept-Encoding, Origin
Content-Encoding: gzip
Content-Length: 235
Keep-Alive: timeout=2, max=99
Connection: Keep-Alive
Content-Type: text/plain

[Some GZIP'd payload]

浏览器检测到，从 JavaScript 中发起的请求需要被预检。从上面的报文中，我们看到，第 1~12 行发送了一个使用 OPTIONS 方法的“预检请求”。 OPTIONS 是 HTTP/1.1 协议中定义的方法，用以从服务器获取更多信息。该方法不会对服务器资源产生影响。 预检请求中同时携带了下面两个首部字段：

Access-Control-Request-Method: POST
Access-Control-Request-Headers: X-PINGOTHER

首部字段 Access-Control-Request-Method 告知服务器，实际请求将使用 POST 方法。首部字段 Access-Control-Request-Headers 告知服务器，实际请求将携带两个自定义请求首部字段：X-PINGOTHER 与 Content-Type。服务器据此决定，该实际请求是否被允许。

第14~26 行为预检请求的响应，表明服务器将接受后续的实际请求。重点看第 17~20 行：

Access-Control-Allow-Origin: http://foo.example
Access-Control-Allow-Methods: POST, GET, OPTIONS
Access-Control-Allow-Headers: X-PINGOTHER, Content-Type
Access-Control-Max-Age: 86400

首部字段 Access-Control-Allow-Methods 表明服务器允许客户端使用 POST, GET 和 OPTIONS 方法发起请求。该字段与 HTTP/1.1 Allow: response header 类似，但仅限于在需要访问控制的场景中使用。

首部字段 Access-Control-Allow-Headers 表明服务器允许请求中携带字段 X-PINGOTHER 与 Content-Type。与 Access-Control-Allow-Methods 一样，Access-Control-Allow-Headers 的值为逗号分割的列表。

最后，首部字段 Access-Control-Max-Age 表明该响应的有效时间为 86400 秒，也就是 24 小时。在有效时间内，浏览器无须为同一请求再次发起预检请求。请注意，浏览器自身维护了一个最大有效时间，如果该首部字段的值超过了最大有效时间，将不会生效。

预检请求与重定向

大多数浏览器不支持针对于预检请求的重定向。如果一个预检请求发生了重定向，浏览器将报告错误：

The request was redirected to 'https://example.com/foo', which is disallowed for cross-origin requests that require preflight

Request requires preflight, which is disallowed to follow cross-origin redirect

CORS 最初要求该行为，不过在后续的修订中废弃了这一要求。

在浏览器的实现跟上规范之前，有两种方式规避上述报错行为：

• 在服务端去掉对预检请求的重定向；
• 将实际请求变成一个简单请求。

如果上面两种方式难以做到，我们仍有其他办法：

• 使用简单请求模拟预检请求，用以探查预检请求是否重定向到其他 URL（使用  Response.url 或 XHR.responseURL）；
• 向上一步中获得的 URL 发起请求。

不过，如果请求由于缺失 Authorization 字段而引起一个预检请求，则这一方法将无法使用。这种情况只能由服务端进行更改。

附带身份凭证的请求

Fetch 与 CORS 的一个有趣的特性是，可以基于  HTTP cookies 和 HTTP 认证信息发送身份凭证。一般而言，对于跨域 XMLHttpRequest 或 Fetch 请求，浏览器不会发送身份凭证信息。如果要发送凭证信息，需要设置 XMLHttpRequest 的某个特殊标志位。

本例中，http://foo.example 的某脚本向 http://bar.other 发起一个GET 请求，并设置 Cookies：

var invocation = new XMLHttpRequest();
var url = 'http://bar.other/resources/credentialed-content/';

function callOtherDomain(){
  if(invocation) {
    invocation.open('GET', url, true);
    invocation.withCredentials = true;
    invocation.onreadystatechange = handler;
    invocation.send();
  }
}

第 7 行将 XMLHttpRequest 的 withCredentials 标志设置为 true，从而向服务器发送 Cookies。因为这是一个简单 GET 请求，所以浏览器不会对其发起“预检请求”。但是，如果服务器端的响应中未携带 Access-Control-Allow-Credentials: true ，浏览器将不会把响应内容返回给请求的发送者。

客户端与服务器端交互示例如下：

GET /resources/access-control-with-credentials/ HTTP/1.1
Host: bar.other
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3pre) Gecko/20081130 Minefield/3.1b3pre
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Connection: keep-alive
Referer: http://foo.example/examples/credential.html
Origin: http://foo.example
Cookie: pageAccess=2

HTTP/1.1 200 OK
Date: Mon, 01 Dec 2008 01:34:52 GMT
Server: Apache/2.0.61 (Unix) PHP/4.4.7 mod_ssl/2.0.61 OpenSSL/0.9.7e mod_fastcgi/2.4.2 DAV/2 SVN/1.4.2
X-Powered-By: PHP/5.2.6
Access-Control-Allow-Origin: http://foo.example
Access-Control-Allow-Credentials: true
Cache-Control: no-cache
Pragma: no-cache
Set-Cookie: pageAccess=3; expires=Wed, 31-Dec-2008 01:34:53 GMT
Vary: Accept-Encoding, Origin
Content-Encoding: gzip
Content-Length: 106
Keep-Alive: timeout=2, max=100
Connection: Keep-Alive
Content-Type: text/plain

[text/plain payload]

即使第 11 行指定了 Cookie 的相关信息，但是，如果 bar.other 的响应中缺失 Access-Control-Allow-Credentials: true（第 19 行），则响应内容不会返回给请求的发起者。

附带身份凭证的请求与通配符

对于附带身份凭证的请求，服务器不得设置 Access-Control-Allow-Origin 的值为“*”。

这是因为请求的首部中携带了 Cookie 信息，如果 Access-Control-Allow-Origin 的值为“*”，请求将会失败。而将 Access-Control-Allow-Origin 的值设置为 http://foo.example，则请求将成功执行。

另外，响应首部中也携带了 Set-Cookie 字段，尝试对 Cookie 进行修改。如果操作失败，将会抛出异常。

HTTP 响应首部字段EDIT

本节列出了规范所定义的响应首部字段。上一小节中，我们已经看到了这些首部字段在实际场景中是如何工作的。

Access-Control-Allow-Origin

响应首部中可以携带一个 Access-Control-Allow-Origin 字段，其语法如下:

Access-Control-Allow-Origin: <origin> | *

其中，origin 参数的值指定了允许访问该资源的外域 URI。对于不需要携带身份凭证的请求，服务器可以指定该字段的值为通配符，表示允许来自所有域的请求。

例如，下面的字段值将允许来自 http://mozilla.com 的请求：

Access-Control-Allow-Origin: http://mozilla.com

如果服务端指定了具体的域名而非“*”，那么响应首部中的 Vary 字段的值必须包含 Origin。这将告诉客户端：服务器对不同的源站返回不同的内容。

Access-Control-Expose-Headers

Access-Control-Expose-Headers 首部字段指定了服务端允许的首部字段集合。

Access-Control-Expose-Headers: X-My-Custom-Header, X-Another-Custom-Header

服务器允许请求中携带 X-My-Custom-Header 和 X-Another-Custom-Header 这两个字段。

Access-Control-Max-Age

Access-Control-Max-Age 首部字段指明了预检请求的响应的有效时间。

Access-Control-Max-Age: <delta-seconds>

delta-seconds 表示该响应在多少秒内有效。

Access-Control-Allow-Credentials

Access-Control-Allow-Credentials 首部字段用于预检请求的响应，表明服务器是否允许 credentials 标志设置为 true 的请求。请注意：简单 GET 请求不会被预检；如果对此类请求的响应中不包含该字段，浏览器不会将响应返回给请求的调用者。

Access-Control-Allow-Credentials: true

上文已经讨论了附带身份凭证的请求。

Access-Control-Allow-Methods

Access-Control-Allow-Methods 首部字段用于预检请求的响应。其指明了实际请求所允许使用的 HTTP 方法。

Access-Control-Allow-Methods: <method>[, <method>]*

相关示例见这里。

Access-Control-Allow-Headers

Access-Control-Allow-Headers 首部字段用于预检请求的响应。其指明了实际请求中允许携带的首部字段。

Access-Control-Allow-Headers: <field-name>[, <field-name>]*

HTTP 请求首部字段EDIT

本节列出了可用于发起跨域请求的首部字段。请注意，这些首部字段无须手动设置。 当开发者使用 XMLHttpRequest 对象发起跨域请求时，它们已经被设置就绪。

Origin

Origin 首部字段表明预检请求或实际请求的源站。

Origin: <origin>

origin 参数的值为源站 URI。它不包含任何路径信息，只是服务器名称。

Note: 有时候将该字段的值设置为空字符串是有用的，例如，当源站是一个 data URL 时。

注意，不管是否为跨域请求，ORIGIN 字段总是被发送。

Access-Control-Request-Method

Access-Control-Request-Method 首部字段用于预检请求。其作用是，将实际请求所使用的 HTTP 方法告诉服务器。

Access-Control-Request-Method: <method>

相关示例见这里。

Access-Control-Request-Headers

Access-Control-Request-Headers 首部字段用于预检请求。其作用是，将实际请求所携带的首部字段告诉服务器。

Access-Control-Request-Headers: <field-name>[, <field-name>]*

相关示例见这里。

规范EDIT

Specification	Status	Comment
Fetch CORS	Living Standard	New definition; supplants CORS specification.
CORS	Recommendation	Initial definition.

浏览器兼容性EDIT

• Desktop
• Mobile

Feature	Chrome	Firefox (Gecko)	Internet Explorer	Opera	Safari
Basic support	4	3.5	8 (via XDomainRequest) 10	12	4

注：

• IE 10 提供了对规范的完整支持，但在较早版本（8 和 9）中，CORS 机制是借由 XDomainRequest 对象完成的。
• Firefox 3.5 引入了对 XMLHttpRequests 和 Web 字体的跨域支持（但最初的实现并不完整，这在后续版本中得到完善）；Firefox 7 引入了对 WebGL 贴图的跨域支持；Firefox 9 引入了对 drawImage 的跨域支持。

参见EDIT

• Code Samples Showing XMLHttpRequest and Cross-Origin Resource Sharing
• Cross-Origin Resource Sharing From a Server-Side Perspective (PHP, etc.)
• Cross-Origin Resource Sharing specification
• XMLHttpRequest
• Fetch API
• Using CORS with All (Modern) Browsers
• Using CORS - HTML5 Rocks

https://developer.mozilla.org/zh-CN/docs/Web/HTTP/Access_control_CORS

什么是CORS?

Cross-origin resource sharing(跨域资源共享),是一个W3C标准,它允许你向一个不同源的服务器发出XMLHttpRequest请求,从而克服了ajax只能请求同源服务的限制.并且也可以通过灵活的设置,来指定什么样的请求是可以被授权的.

什么是跨域?

假设你在http://xxx.com/test/下有一个js文件,从这个js里发出一个ajax请求请求后端服务,按照如下情况判定:

请求地址	原因	结果
http://xxx.com/xxxx/action	同一域名,不同文件夹	非跨域
http://xxx.com/test/action	同一域名,同一文件夹	非跨域
http://a.xxx.com/test/action	不同域名,文件路径相同	跨域
http://xxx.com:8080/test/action	同一域名,不同端口	跨域
https://xxx.com/test/action	同一域名,不同协议	跨域

还有那些其他的跨域解决方案?

• JSONP : 动态添加一个<script>标签，而script标签的src属性是没有跨域的限制的。这样说来，这种跨域方式其实与ajax XmlHttpRequest协议无关了,而缺点也很明显,它只支持GET请求而不支持POST等其它类型的HTTP请求；它只支持跨域HTTP请求这种情况，不能解决不同域的两个页面之间如何进行JavaScript调用的问题

• NGINX代理 : 通过一个代理服务器,将跨域的请求转发,如:前端JS在http://www.demo.com/a.js,后端是http://www.abc.com/app/action,通过代理可将后端的地址转换成http://www.demo/app/action,这样,从前端发起的请求,就不存在跨域的情况了

然后CORS是支持所有类型的HTTP请求,并且也只是服务端进行设置即可,但是缺点就是老的浏览器不支持CORS(如:IE7,7,8,等)

思路

CORS的响应头

• Access-Control-Allow-Origin : 必须的,允许的域名,如果设置*,则表示接受任何域名

• Access-Control-Allow-Credentials : 非必须的,表示是否允许发送Cookie,注意,当设置为true的时候,客户端的ajax请求,也需要将withCredentials属性设置为true

• Access-Control-Expose-Headers : 非必须的,表示客户端能拿到的header,默认情况下XMLHttpRequest的getResponseHeader方法只能拿到几个基本的header,如果有自定义的header要获取的话,则需要设置此值

• Access-Control-Request-Method : 必须的,表示CORS上会使用到那些HTTP方法

• Access-Control-Request-Headers : 必须的,表示CORS上会有那些额外的的有信息

CORS将请求分为两种类型

两种类型分别为简单请求和非简单请求,同时满足以下两大条件的请求被定义为是简单请求:

• 请求方法是以下三种之一:

• HEAD

• GET

• POST

• HTTP头信息不超出以下几种字段:

• Accept

• Accept-Language

• Content-Language

• Last-Event-ID

• Content-Type：只限于三个值application/x-www-form-urlencoded、multipart/form-data、text/plain

对于非简单请求,浏览器会自动发一个预检请求,这个请求是OPTIONS方法的,主要是询问服务器当前请求是否在允许范围内

实现

1.方式A:使用@CrossOrigin来标记指定的方法(小范围跨域)

@RequestMapping(value = "add", method = RequestMethod.GET)
@CrossOrigin(methods = { RequestMethod.GET, RequestMethod.POST }, origins = "*")
public RestResponse<Integer> add(Integer a, Integer b) {
    return new RestResponse<>(demoService.add(a, b));
}

2.方式B:使用spring boot的默认配置来设定全局跨域

endpoints.cors.allow-credentials=
endpoints.cors.allowed-headers=
endpoints.cors.allowed-methods=GET
endpoints.cors.allowed-origins=
endpoints.cors.exposed-headers=
endpoints.cors.max-age=1800

3.方式C:使用WebMvcConfigurer自定义配置跨域

定义CorsRegistrationConfig类

public static class CorsRegistrationConfig {
    //描述 : 扫描地址
    private String mapping = "/**";
    //描述 : 允许证书
    private Boolean allowCredentials = null;
    //描述 : 允许的域
    private String allowedOrigins = "*";
    //描述 : 允许的方法
    private String allowedMethods = "POST,GET,DELETE,PUT";
    //描述 : 允许的头信息
    private String allowedHeaders = "*";

    .........省略
}

定义CorsConfig类

@Configuration
@ConfigurationProperties(prefix = "org.itkk.cors")
@Validated
public class CorsConfig {

  //描述 : 跨域信息
  @NotNull
  private Map<String, CorsRegistrationConfig> config;

  .....省略

}

定义重写addCorsMappings方法

  @Bean
  public WebMvcConfigurer corsConfigurer() {
    return new WebMvcConfigurerAdapter() {
      @Override
      public void addCorsMappings(CorsRegistry registry) {
        //扫描地址
        if (!CollectionUtils.isEmpty(config)) {
          Iterator<String> keys = config.keySet().iterator();
          while (keys.hasNext()) {
            String key = keys.next();
            CorsRegistrationConfig item = config.get(key);
            CorsRegistration cr = registry.addMapping(item.getMapping());
            if (item.getAllowCredentials() != null) {
              cr.allowCredentials(item.getAllowCredentials());
            }
            if (StringUtils.isNotBlank(item.getAllowedOrigins())) {
              String[] allowedOriginArray = item.getAllowedOrigins().split(",");
              cr.allowedOrigins(allowedOriginArray);
            }
            if (StringUtils.isNotBlank(item.getAllowedMethods())) {
              String[] allowedMethodArray = item.getAllowedMethods().split(",");
              cr.allowedMethods(allowedMethodArray);
            }
            if (StringUtils.isNotBlank(item.getAllowedHeaders())) {
              String[] allowedHeaderArray = item.getAllowedHeaders().split(",");
              cr.allowedHeaders(allowedHeaderArray);
            }
          }
        }
      }
    };
  }

配置文件,可根据不同的mapping设置不同的cors规则

org.itkk.cors.config.demo.mapping=/**
org.itkk.cors.config.demo.allowCredentials=
org.itkk.cors.config.demo.allowedOrigins=
org.itkk.cors.config.demo.allowedMethods=
org.itkk.cors.config.demo.allowedHeaders=

使用jquery,在跨域场景下进行测试

    $(function(){
        $.ajax({
            url:'http://127.0.0.1:8080/demo/c',
            headers:{
                'aheader':'111'
            },
            type:'GET',
            dataType:'json',
            success:function(data){
                console.log(1);
                console.log(data);
                console.log(2);

            }
        });
    });

代码仓库 (博客配套代码)

• udf-starter : 基础项目,脚手架,框架

• udf-sample : 集成样例

结束

演示了单spring boot的应用的,在后续的章节中,会找机会写一下在微服务场景下(spring cloud)的跨域设置

http://www.cnblogs.com/itkk/p/7447118.html

运行时何处会添加responseHeader的Origin？

prehandle:

RequestMapping方法(该方法执行结束后添加)

posthandle

aftercomplish

crossOrigin注解中的method，如果写了会覆盖requestMethod中指定的，不写的话默认就是requestMethod中指定的。

request中默认会设定自己的Origin。

如上链接官方文档所说，只有简单请求才会触发preflight.

所以postman测试本地程序时：

get方法，以及body为空的post,设置的跨域不起作用，request中header的origin为空。就跟没设置一样。 浏览器get也不起作用
body包含了文件的post,设置的跨域起作用。此时request中header的origin不为空，response也不为空。（可以查看本地的origin）

注意maxAge，如果某个地方未能跨域访问，由于其缓存，导致其它本来能跨域访问的也不能访问了。

/** 匹配的是 /开始的所有路径及文件，包括//domain,也包括/domain
/* 匹配的是/开始的，包括/domain,但不包括//domain，也不包括/domain/file

所以如果设置了但不起作用，很可能是以下两个原因：

全局设定时路径没匹配对
多个路径的情况下有遗漏的路径没有设定，缓存的原因。

https://blog.csdn.net/yangyi1101/article/details/77307312

Using pre-signed URLs to upload a file to a private S3 bucket

https://sanderknape.com/2017/08/using-pre-signed-urls-upload-file-private-s3-bucket/