#

在了解什么是同源和跨域之前我们首先要明确在浏览器中什么是域。浏览器中由协议名、服务器地址、端口号组成一个域。默认网站的端口为80可以省略

同源指的是两个 URL 的协议、域名、端口一致,反之,则是跨域

出现跨域的根本原因:浏览器的同源策略不允许非同源的 URL 之间进行资源的交互。

网页访问资源时,只要 url 的协议名、服务器地址、端口号中任何一个发生了改变就会产生跨域问题。

# 同源策略

为了确保用户的上网安全,浏览器采用了同源策略来防止入侵。如果两个页面的协议,域名和端口都相同,则两个页面具有相同的源。。同源策略就是浏览器规定网页请求数据只能在同源站点中请求,不能跨域请求资源。浏览器规定,A 网站的 JavaScript,不允许和非同源的网站 C 之间,进行资源的交互。虽然我们的网络请求可以正常发送,服务器也会正常响应资源,但到浏览器这层资源就会被拦截下来,我们的 js 代码无法得到数据。例如:

①无法读取非同源网页的 Cookie、LocalStorage 和 IndexedDB

②无法接触非同源网页的 DOM

③无法向非同源地址发送 Ajax 请求

数据被拦截

# 跨域解决方法

现如今,实现跨域数据请求,最主要的两种解决方案,分别是 JSONP 和 CORS。

JSONP:出现的早,兼容性好(兼容低版本 IE)。是前端程序员为了解决跨域问题,被迫想出来的一种临时解决方案。缺点是只支持 GET 请求,不支持 POST 请求。

CORS:出现的较晚,它是 W3C 标准,属于跨域 Ajax 请求的根本解决方案。支持 GET 和 POST 请求。缺点是不兼容某些低版本的浏览器。

# JSONP

JSONP (JSON with Padding) 是 JSON 的一种 “使用模式”,可用于解决主流浏览器的跨域数据访问的问题。

由于浏览器同源策略的限制,网页中无法通过 Ajax 请求非同源的接口数据。但是 <script> 标签不受浏览器同源策略的影响,可以通过 src 属性,请求非同源的 js 脚本。

因此,JSONP 的实现原理,就是通过 <script> 标签的 src 属性,请求跨域的数据接口,并通过函数调用的形式,接收跨域接口响应回来的数据。

//在这个标签页面定义函数
<script>
    function foo(a,b){
        return a + b;
    }
</script>
//在另一个标签页调用函数
<script src="http://函数定义地址?callback=foo&a=10s&b=20"></script>

由于 JSONP 是通过 <script> 标签的 src 属性,来实现跨域数据获取的,所以,JSONP 只支持 GET 数据请求,不支持 POST 请求。

JSONP Ajax 之间没有任何关系,不能把 JSONP 请求数据的方式叫做 Ajax,因为 JSONP 没有用到 XMLHttpRequest 这个对象。

# CORS

CORS (Cross-Origin Resource Sharing,跨域资源共享)由一系列 HTTP 响应头组成,这些 HTTP 响应头决定浏览器是否阻止前端 JS 代码跨域获取资源

①CORS 主要在服务器端进行配置。客户端浏览器无须做任何额外的配置,即可请求开启了 CORS 的接口。

②CORS 在浏览器中有兼容性。只有支持 XMLHttpRequest Level2 的浏览器,才能正常访问开启了 CORS 的服务端接口(例如:IE10+、Chrome4+、FireFox3.5+)。

# CORS 响应头部 - Access-Control-Allow-Origin

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

Access-Control-Allow-Origin:<origin> | * //*为通配符

其中,origin 参数的值指定了允许访问该资源的外域 URL。

例如,下面的字段值将只允许来自 http://asuhe.fun 的请求:

res.setHeader('Access-Control-Allow-Origin','http://asuhe.fun')

# CORS 响应头部 - Access-Control-Allow-Headers

默认情况下,CORS 支持客户端向服务器发送如下的 9 个请求头:

Accept、Accept-Language、Content-Language、DPR、Downlink、Save-Data、Viewport-Width、Width 、Content-Type (值仅限于 text/plain、multipart/form-data、application/x-www-form-urlencoded 三者之一)

如果客户端向服务器发送了额外的请求头信息,则需要在服务器端,通过 Access-Control-Allow-Headers 对额外的请求头进行声明,否则这次请求会失败!

// 允许客户端额外向服务器发送 Content-Type 请求头和 X-Custom-Header 请求头
res.setHeader('Access-Control-Allow-Headers','Content-Type,X-Custon-Header')

# CORS 响应头部 - Access-Control-Allow-Methods

默认情况下,CORS 仅支持客户端发起 GET、POST、HEAD 请求。

如果客户端希望通过 PUT、DELETE 等方式请求服务器的资源,则需要在服务器端,通过 Access-Control-Alow-Methods 来指明实际请求所允许使用的 HTTP 方法。

// 仅允许 POST,GET,DELETE,HEAD 方法
res.setHeader('Access-Control-Allow-Methods','POST,GET,DELETE,HEAD')
// 允许所有 HTTP 方法
res.setHeader('Access-Control-Allow-Methods','*')

# CORS 请求的分类

# 简单请求

同时满足以下两大条件的请求,就属于简单请求:

① 请求方式:GET、POST、HEAD 三者之一

② HTTP 头部信息不超过以下几种字段:无自定义头部字段、Accept、Accept-Language、Content-Language、DPR、Downlink、Save-Data、Viewport-Width、Width 、Content-Type(只有三个值 application/x-www-form-urlencoded、multipart/form-data、text/plain)

# 预检请求

只要符合以下任何一个条件的请求,都需要进行预检请求:

① 请求方式为 GET、POST、HEAD 之外的请求 Method 类型

② 请求头中包含自定义头部字段

③ 向服务器发送了 application/json 格式的数据

在浏览器与服务器正式通信之前,浏览器会先发送 OPTION 请求进行预检,以获知服务器是否允许该实际请求,所以这一次的 OPTION 请求称为 “预检请求”。服务器成功响应预检请求后,才会发送真正的请求,并且携带真实数据。

其中 OPTION 预检请求的请求体为空,若预检成功则服务器返回的响应体也为空

简单请求的特点:客户端与服务器之间只会发生一次请求。

预检请求的特点:客户端与服务器之间会发生两次请求,OPTION 预检请求成功之后,才会发起真正的请求。