跨域nginx，CORS

浏览器的同源策略是浏览器上为安全性考虑实施的非常重要的安全策略。
从一个域上加载的脚本不允许访问另外一个域的文档属性。
举个例子：比如一个恶意网站的页面通过iframe嵌入了银行的登录页面（二者不同源），
如果没有同源限制，恶意网页上的javascript脚本就可以在用户登录银行的时候获取用户名和密码。
何谓同源:URL由协议、域名、端口和路径组成，如果两个URL的协议、域名和端口相同，则表示它们同源。
在浏览器中，<script>、<img>、<iframe>、<link>等标签都可以加载跨域资源，而不受同源限制，
但浏览器会限制脚本中发起的跨域请求（ajax请求能发起，能正常返回数据，只是浏览器拒绝了拦截了返回结果）。比如，使用 XMLHttpRequest 对象和Fetch发起 HTTP 请求就必须遵守同源策略。
Web 应用程序通过 XMLHttpRequest 对象或Fetch能且只能向同域名的资源发起 HTTP 请求，而不能向任何其它域名发起请求。
不允许跨域访问并非是浏览器限制了发起跨站请求，而是跨站请求可以正常发起，但是返回结果被浏览器拦截了。
最好的例子是CSRF跨站攻击原理，请求是发送到了后端服务器,无论是否设置允许跨域,
有些浏览器不允许从HTTPS跨域访问HTTP，比如Chrome和Firefox，这些浏览器在请求还未发出的时候就会拦截请求,这是特例。

nginx是一台静态资源服务器。当浏览器输入网址，经过域名解析--寻找IP地址---到达nginx服务器，nginx返回给浏览器相应的html，css，js等等资源，一次会话完成。

如果有跨域资源ajax，nginx服务器需要对其进行配置转发，再次请求该不同域处的服务器资源，这样浏览器就能接受到该跨域资源。

解决方法：

我只关注两种，其余的不想管，因为我们毕业出来，实际应用中就没有了其余的方式。

一：代理服务器（需要请求的跨域资源，你的服务器帮你去请求到本服务器，然后以本服务器返回给你，就是本域返回给你跨域的信息，所以不是跨域的）

二：CORS，CORS全称是"跨域资源共享"（Cross-origin resource sharing),CORS需要浏览器和服务器同时支持。目前，所有浏览器都支持该功能
(IE浏览器不能低于IE10)，因此，实现CORS通信的关键是服务器。只要服务器实现了CORS接口，就可以跨源通信。

当出现403跨域错误的时候 No 'Access-Control-Allow-Origin' header is present on the requested resource，需要给Nginx服务器配置响应的header参数：

一、解决方案

只需要在Nginx的配置文件中配置以下参数：

location / {

  add_header Access-Control-Allow-Origin *;

  add_header Access-Control-Allow-Headers "Origin, X-Requested-With, Content-Type, Accept";

  add_header Access-Control-Allow-Methods "GET, POST, OPTIONS";

}

二、解释

1. Access-Control-Allow-Origin

服务器默认是不被允许跨域的。给Nginx服务器配置Access-Control-Allow-Origin *后，表示服务器可以接受所有的请求源（Origin）,即接受所有跨域的请求。

2. Access-Control-Allow-Headers 是为了防止出现以下错误：

Request header field Content-Type is not allowed by Access-Control-Allow-Headers in preflight response.

这个错误表示当前请求Content-Type的值不被支持。其实是我们发起了"application/json"的类型请求导致的。这里涉及到一个概念：预检请求（preflight request）,请看下面"预检请求"的介绍。

3. Access-Control-Allow-Methods 是为了防止出现以下错误：

Content-Type is not allowed by Access-Control-Allow-Headers in preflight response.

发送"预检请求"时，需要用到方法 OPTIONS ,所以服务器需要允许该方法。

三、预检请求（preflight request）

其实上面的配置涉及到了一个W3C标准：CROS,全称是跨域资源共享 (Cross-origin resource sharing)，它的提出就是为了解决跨域请求的。

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

其实Content-Type字段的类型为application/json的请求就是上面所说的搭配某些 MIME 类型的 POST 请求,CORS规定，

Content-Type不属于以下MIME类型的，都属于预检请求：

application/x-www-form-urlencoded

multipart/form-data

text/plain

所以 application/json的请求会在正式通信之前，增加一次"预检"请求，这次"预检"请求会带上头部信息 Access-Control-Request-Headers: Content-Type：

OPTIONS /api/test HTTP/1.1

Origin: http://foo.example

Access-Control-Request-Method: POST

Access-Control-Request-Headers: Content-Type

... 省略了一些

服务器回应时，返回的头部信息如果不包含Access-Control-Request-Headers: Content-Type则表示不接受非默认的的Content-Type。即出现以下错误：

Request header field Content-Type is not allowed by Access-Control-Allow-Headers in preflight response.

本文转载自：https://www.cnblogs.com/wangpenghui522/p/6284355.html
和：http://blog.51cto.com/13523664/2060430