1 什么是跨域请求
在 HTML 中，,
,2 同源策略
概述
- 同源策略是 Netscape 提出的一个著名的安全策略
- 同源策略是浏览器最核心最基础的安全策略
- 现在所有的可支持 Javascript 的浏览器都会使用这个策略
- web构建在同源策略基础之上，浏览器对非同源脚本的限制措施是对同源策略的具体实现
同源策略的含义
- DOM 层面的同源策略：限制了来自不同源的”Document”对象或 JS 脚本，对当前“document”对象的读取或设置某些属性
- Cookie和XMLHttprequest层面的同源策略：禁止 Ajax 直接发起跨域HTTP请求（其实可以发送请求，结果被浏览器拦截，不展示），同时 Ajax 请求不能携带与本网站不同源的 Cookie。
- 同源策略的非绝对性：
<script><img><iframe><link><video><audio>等带有src属性的标签可以从不同的域加载和执行资源。 - 其他插件的同源策略：
flash、java applet、silverlight、googlegears等浏览器加载的第三方插件也有各自的同源策略，只是这些同源策略不属于浏览器原生的同源策略，如果有漏洞则可能被黑客利用，从而留下XSS攻击的后患。
同源的具体含义
- 域名、协议、端口有一个不同就不是同源，三者均相同，这两个网站才是同源
同源策略的作用
为了限制不同源之间的交互，从而能够有效避免 XSS 、 CSFR 等浏览器层面的攻击。XSS 指的是恶意攻击者往 Web 页面里插入恶意 HTML 代码，利用的是用户对指定网站的信任。而 CSFR 指的是跨站请求伪造，是攻击者通过一些技术手段欺骗用户的浏览器去访问一个自己曾经认证过的网站并执行一些操作（如发邮件，发消息，甚至财产操作如转账和购买商品）。由于浏览器曾经认证过，所以被访问的网站会认为是真正的用户操作而去执行。这利用了Web中用户身份验证的一个漏洞： 简单的身份验证只能保证请求是发自某个用户的浏览器，却不能保证请求本身是用户自愿发出的。这实际上利用的是网站对用户网页浏览器的信任。所以根据浏览器的是否同源判定，可以有选择的限制网站的一些行为。比如非同源的站点会被限制访问 cookie 、 localStorage 以及 IndexDB ，同时也无法获取网页 DOM 以及 Java 对象，甚至 AJAX 的请求也会被拦截。这样一来，就能够有效限制利用浏览器以及历史访问站点来进行攻击的目的。
3 跨域解决方法
1 JSONP
原理：
- JSONP 是一种非官方的跨域数据交互协议
- JSONP 本质上是利用
<script><img><iframe>等标签不受同源策略限制，可以从不同域加载并执行资源的特性，来实现数据跨域传输。 - JSONP由两部分组成：回调函数和数据。回调函数是当响应到来时应该在页面中调用的函数，而数据就是传入回调函数中的JSON数据。
- JSONP 的理念就是，与服务端约定好一个回调函数名，服务端接收到请求后，将返回一段 Javascript，在这段 Javascript 代码中调用了约定好的回调函数，并且将数据作为参数进行传递。当网页接收到这段 Javascript 代码后，就会执行这个回调函数，这时数据已经成功传输到客户端了。
2 Nginx反向代理
3 Nginx配置
众所周知，开启跨域支持是需要服务端配置Access-Control-Allow-Origin，Access-Control-Allow-Methods，Access-Control-Allow-Headers这些请求头的，那么既然有了Nginx做了中间层代理服务，就算 server 不给我们开启这些，我们完全也能够自给自足。
4 CORS
CORS（ Cross-Origin Resource Sharing ）是指跨域资源共享，它是一个浏览器侧的机制，能够允许服务器标示除了它自己以外的其它域，这样浏览器就可以进行跨域访问加载资源。 一般现代浏览器都支持 CORS 跨域，只有那种古老的浏览器，比如 IE10 以下的才不支持。 这意味着，实际上浏览器虽然会采取同源策略来限制跨域访问，但是同时又给服务端提供了一个选择，即通过 CORS 来可选的提供跨域能力。CORS 是浏览器提供的能力，而实现 CORS 的控制和通信是在服务端进行。也就是只要服务端对相应域允许 CORS ，那么便可进行跨域通信。
跨源资源共享 Cross-Origin Resource Sharing(CORS) 是一个新的 W3C 标准，它新增的一组HTTP首部字段，允许服务端其声明哪些源站有权限访问哪些资源。换言之，它允许浏览器向声明了 CORS 的跨域服务器，发出 XMLHttpReuest 请求，从而克服 Ajax 只能同源使用的限制。 另外，规范也要求对于非简单请求，浏览器必须首先使用 OPTION 方法发起一个预检请求(preflight request)，从而获知服务端是否允许该跨域请求，在服务器确定允许后，才发起实际的HTTP请求。
一、CORS是如何工作的？
基于Web的资源共享涉及到两个基本的角色，即资源的提供者和消费者。针对我们前面演示的应用场景，即显示在浏览器中的某个Web页面通过调用Web API的方式来获取它所需的资源，资源提供者为Web API本身，通过发送Ajax请求来调用Web API的JavaScript程序为资源的消费者。
CORS旨在定义一种规范让浏览器在接收到从提供者获取的资源时能够正决定是否应该将此资源分发给消费者作进一步处理。**CROS利用资源提供者的显式授权来决定目标资源是否应该与消费者共享。换句话说，浏览器需要得到提供者的授权之后才会将其提供的资源分发给消费者。**那么，资源的提供者如何进行资源的授权，并将授权的结果告诉浏览器呢？
具体的实现其实很简单。如果浏览器 自身提供对CROS的支持，由它发送的请求会携带一个名为“Origin”的报头表明请求页面所在的站点。对于前面我们演示实例中调用Web API获取联系人列表的请求来说，它就具有如下一个“Origin”报头。
1: Origin: http://localhost:95271
资源获取请求被提供者接收之后，它可以根据该报头确定提供的资源需要共享给谁。资源提供者的授权通过一个名为“Access-Control-Allow-Origin”的响应报头来承载，其报头值表示得到授权的站点。一般来说，如果资源的提供者认可了当前请求的“Origin”报头携带的站点，那么它会将该站点作为“Access-Control-Allow-Origin”响应报头的值。
除了指定具体的源并对其作针对性授权之外，资源提供者还可以将“Access-Control-Allow-Origin”报头值设置为“*”对所有消费者授权。换言之，如果作了这样的设置，意味着由其提供的是一种公共资源，所以在做此设置之前需要慎重。如果针对请求着的授权不被允许，资源提供者可以将此响应报头值设置为“null”，或者让响应不具有此报头。
当浏览器接收到包含资源的响应之后，会提取此“Access-Control-Allow-Origin”响应报头的值。如果此值为“*”或者包含的源列表包含此前请求的源（即请求的“Origin”报头值），意味着资源的消费者获取了提供者获取和操作资源的权限，所以浏览器会允许JavaScript程序操作获取的资源。如果此响应报头不存在或者其值为“null”，客户端JavaScript程序针对资源的操作会被拒绝。
二、对响应报头的授权
资源提供者除了通过设置“Access-Control-Allow-Origin”报头对提供的主体资源进行授权之外，还可以通过设置另一个名为“Access-Control-Expose-Headers”的报头对响应报头进行授权。具体来说，此“Access-Control-Expose-Headers”的报头用于设置一组直接暴露给客户端JavaScript程序的响应报头，没有在此列表的响应报头 对于客户端JavaScript程序是不可见的。
但是由此实现的针对响应报头的授权针对简单响应报头是无效的，客户端JavaScript程序总是具有获取它们的权限。对于CORS规范来说，这里所谓的“简单响应报头（Simple Response Header）”包含如下6种。
Cache-Control
Content-Language
Content-Type
Expires
Last-Modified
Pragma
我们知道用于实现Ajax请求的XMLHttpRequest具有一个getResponseHeader方法，调用它会返回一组响应报头的列表。按照这里介绍的针对响应报头的授权原则，只有在“Access-Control-Expose-Headers”报头中指定的报头和简单响应报头才会包含在该方法返回的列表中。
三、预检机制
W3C的CORS规范将跨域资源请求划分为两种类型，一种被称为“简单请求（Simple Request）”。要弄清楚CORS规范将那些类型的跨域资源请求划分为简单请求的范畴，需要额外了解几个名称的含义，其中包括“简单（HTTP）方法（Simple Method）”、“简单（请求）报头（Simple Header）”和“自定义请求报头（Author Request Header/Custom Request Header）”。
CORS规范将GET、HEAD和POST这三个HTTP方法视为“简单HTTP方法”，而将请求报头Accept, Accept-Language, Content-Language以及采用如下三种媒体类型的报头Content-Type称为“简单请求报头”
• application/x-www-form-urlencoded
• multipart/form-data
• text/plain
请求的报头包含两种类型，一类是通过浏览器自动生成的报头，另一种则是由JavaScript程序自行添加的报头（比如调用XMLHttpRequest的setRequestHeader方法可以为生成的Ajax请求添加任意报头），后者被称为“自定义报头”。
CORS规范将服务如下条件的跨域资源请求划分为简单请求：请求采用简单HTTP方法，并且其自定义请求报头空或者所有自定义请求报头均为简单请求报头。之所以作如此划分是因为具有这些特性的请求不是以更新（添加、修改和删除）资源为目的，服务端对请求的处理不会导致自身维护资源的改变。
对于简单跨域资源请求来说，浏览器将两个步骤（取得授权和获取资源）合二为一，由于不涉及到资源的改变，所以不会带来任何副作用（Side Effect）。如果针对请求的处理过程会涉及到对资源的改变，这样做就会有问题了。按照CORS规范的规定，浏览器应该采用一种被称为“预检（Preflight）”的机制来完成非简单跨域资源请求。
所谓预检机制就是说浏览器在发送真正的跨域资源请求前，先发送一个预检请求（Preflight Request）。预检请求为一个采用HTTP-OPTIONS方法的请求，这是一个不包含主体的请求，同时用户凭证相关的报头也会被剔除。基于真正资源请求的一些辅助授权的信息会包含在此预检请求的相应报头中。除了代表请求页面所在站点的“Origin”报头之外，如下所示的是两个典型的请求报头。
• Access-Control-Request-Method：真正跨域资源请求采用的HTTP方法。
• Access-Control-Request-Headers：真正跨域资源请求携带的自定义报头列表。
资源的提供者在接收到预检请求之后，根据其提供的相关报头进行授权检验，具体的检验逻辑即包括确定请求站点是否值得信任，以及请求采用HTTP方法和自定义报头是否被允许。如果预检请求没有通过授权检验，资源提供者一般会返回一个状态为“400， Bad Reuqest”的响应。反之则会返回一个状态为“200， OK”的响应，授权相关信息会包含在响应报头中。除了上面介绍的“Access-Control-Allow-Origin”和“Access-Control-Expose-Headers”报头之外，预检请求的响应还具有如下3个典型的报头。
• Access-Control-Allow-Methods：跨域资源请求允许采用的HTTP方法列表。
• Access-Control-Allow-Headers：跨域资源请求允许携带的自定义报头列表。
• Access-Control-Max-Age：浏览器可以将响应结果进行缓存的时间（单位为秒），这样可以让浏览器避免频繁地发送预检请求。
浏览器在接收到预检响应之后，会根据响应报头确定后续发送的真正跨域资源请求是否会被接受，相关的检验包括针对服务端允许站点以及HTTP方法和自定义请求报头（利用响应报头“Access-Control-Allow-Methods”和“Access-Control-Allow-Headers”）的检验。具体的检验逻辑如下
• 通过请求的“Origin”报头表示的源站点必须存在于“Access-Control-Allow-Origin”响应报头标识的站点列表中。
• 响应报头“Access-Control-Allow-Methods”不存在，或者预检请求的“Access-Control-Request-Method”报头表示的请求方法在其列表之内。
• 预检请求的“Access-Control-Request-Headers”报头存储的报头名称均在响应报头“Access-Control-Allow-Headers”表示的报头列表之内。
只有在确定服务端一定会接受的情况下，浏览器才会发送真正跨域资源请求。预检响应结果会被浏览器缓存，在“Access-Control-Max-Age”报头设定的时间内，缓存的结果将被浏览器用户进行授权检验，所以在此期间不会再有预检请求发送。
四、是否支持用户凭证
在默认情况下，利用XMLHttpReuqest发送的Ajax请求不会携带用户凭证相关的敏感信息，这里的用户凭证类型包括Cookie、HTTP-Authentication报头以及客户端X.509证书（采用支持客户端证书的TLS/SSL）等。如果需要用户凭证附加到Ajax请求上，需要将XMLHttpReuqest的withCredentials 属性设置为True。
对于CORS来说，是否支持用户凭证也是授权检验的一个环节。换句话说，只有在服务端显式支持用户凭证的情况下，携带了用户凭证的请求才会被认为是有效的。在W3C的CORS规范来说，服务端利用响应报头“Access-Control-Allow-Credentials”来表明自身是否支持用户凭证。
也就是说，如果客户客户端JavaScript程序利用一个withCredentials属性为true的XMLHttpReuqest发送了一个跨域资源请求，但是浏览器得到的响应中不具有一个值为“true”的响应报头“Access-Control-Allow-Credentials”，它对获取资源的操作将会浏览器拒绝。
当 nginx 和后端同时配置跨域配置后，会导致跨域配置失败，打开F12会发现，返回的 response 头里有两个Access-Control-Allow-Origin。解决方案：只使用 Nginx 或者后端进行控制跨域，不要两边都配置。
