跨域实践二三事

文章首发

跨域是平常开发中常常开发中常常会接触到的一个重难点知识，何不总结实践一番，今后心中对之了无牵挂。

同源策略

之因此会出现跨域解决方案，是由于同源策略的限制。同源策略规定了若是两个 url 的协议、域名、端口中有任何一个不等，就认定它们跨源了。好比下列表格列出和 http://127.0.0.1:3000 比较的同源检测的结果，

url	结果	缘由
http://127.0.0.1:3000/index	同源
https://127.0.0.1:3000	跨源	协议不一样
https://localhost:3000	跨源	域名不一样
http://127.0.0.1:3001	跨源	端口不一样

那跨源有什么后果呢？概括有三：不能获取 Cookie、LocalStorage、IndexedDB；不能获取 dom 节点；不能进行通常的 Ajax 通讯；跨域解决方案的出现就是为了解决以上痛处。

JSONP 跨域

提到 JSONP 跨域，不得不先提到 script 标签，和 img、iframe 标签相似，这些标签是不受同源策略限制的，JSONP 的核心就是经过动态加载 script 标签来完成对目标 url 的请求。

先来看一段 JSONP 调用的 Headers 部分，字段以下：

Request URL:http://127.0.0.1:3000/?callback=handleResponse
Request Method:GET
Status Code:200 OK
Remote Address:127.0.0.1:3000
复制代码

能够很鲜明地发如今 Request URL 中有一句 ?callback=handleResponse，这个 callback 后面跟着的 handleResponse 即回调函数名（能够任意取），服务端会接收到这个参数而后拼接成形如 handleResponse(JSON) 的形式返还给前端(这也是 JSONP == JSON with padding 的缘由吧)，以下图，这时候浏览器就会自动调用咱们事先定义好的 handleResponse 函数。

前端代码示例：(源为 http://127.0.0.1:3001)

function handleResponse(res) {
  console.log(res) // {text: "jsonp"}
}

const script = document.createElement('script')
script.src = 'http://127.0.0.1:3000?callback=handleResponse'
document.head.appendChild(script)
复制代码

服务端代码示例：(源为 http://127.0.0.1:3000)

const server = http.createServer((req, res) => {
  if (~req.url.indexOf('?callback')) { // 简单处理 JSONP 跨域的时候
    const obj = {
      "text": 'jsonp',
    }
    const callback = req.url.split('callback=')[1]
    const json = JSON.stringify(obj)
    const build = callback + `(${json})`
    res.end(build) // 这里返还给前端的是拼接好的 JSON 对象
  }
});
复制代码

能够看出 JSONP 具备直接访问响应文本的优势，可是要想确认 JSONP 是否请求失败并不容易，由于 script 标签的 onerror 事件还未获得浏览器普遍的支持，此外它仅能支持 GET 方式调用。

CORS 跨域

CORS(Cross-Origin Resource Sharing) 能够理解为增强版的 Ajax，也是目前主流的跨域解决方案。它的核心思想即前端与后端进行 Ajax 通讯时，经过自定义 HTTP 头部设置从而决定请求或响应是否生效。

好比前端代码(url 为 http://127.0.0.1:3001)写了段 Ajax，代码以下：

const xhr = new XMLHttpRequest()
xhr.onreadystatechange = function () {
  if (xhr.readyState === 4) {
    if (xhr.status >= 200 && xhr.status < 300 || xhr.status === 304) {
      console.log('responseTesx:' + xhr.responseText)
    }
  }
}
xhr.open('get', 'http://127.0.0.1:3000', true)
xhr.send()
复制代码

由于端口不一致的关系这时候致使不一样源了，这时候会在 Request Headers 中发现多了这么一行字段，

Origin: http://127.0.0.1:3001
复制代码

并且控制台中会报出以下错误:

Failed to load http://127.0.0.1:3000/: Response to preflight request doesn't pass access control check: No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'http://127.0.0.1:3001' is therefore not allowed access.
复制代码

这时候就须要在服务端设置字段 Access-Control-Allow-Origin，它的做用就是设置容许来自什么源的请求，若是值设置为 *，代表容许来自任意源的请求。服务端代码示例以下：

http.createServer((req, res) => {
  res.setHeader('Access-Control-Allow-Origin', 'http://127.0.0.1:3001') // 设置容许来自 http://127.0.0.1:3001 源的请求
})
复制代码

CORS 分为简单请求以及非简单请求。能够这么区分，若是请求方法为 POST、GET、HEAD 时为简单请求，其它方法如 PUT、DELETE 等为非简单请求，若是是非简单请求的话，能够在 chrome 的 Network 中看到多了一次 Request Method 为 OPTIONS 的请求。以下图:

能够把这个请求称为预请求，用白话文翻译下，浏览器询问服务器，'服务器大哥，我此次要进行 PUT 请求，你给我发张通行证呗'，服务器大哥见浏览器小弟这么殷勤，因而给了它发了张通行证，叫做 Access-Control-Allow-Methods:PUT，接着浏览器就能愉快地进行 PUT 请求了。服务端代码示例以下：

http.createServer((req, res) => {
  res.setHeader('Access-Control-Allow-Origin', 'http://127.0.0.1:3001')
  res.setHeader('Access-Control-Allow-Methods', 'http://127.0.0.1:3001')
})
复制代码

聊完简单请求和非简单请求的区别后，再来看看如何利用 CORS 实现 Cookie 的跨域传送，首先在服务器随意设置个 Cookie 值下发到浏览器，若是非跨域的状况下，浏览器再次请求服务器时就会带上服务器给的 Cookie，可是跨域的时候怎么办呢？不卖关子了，需在服务端设置 Access-Control-Allow-Credentials 字段以及在客户端设置 withCredentials 字段，二者缺一不可，代码以下：

前端代码示例：(源为 http://127.0.0.1:3001)

const xhr = new XMLHttpRequest()
...
xhr.withCredentials = true // 传 cookie 的时候前端要作的
xhr.open('get', 'http://127.0.0.1:3000', true)
xhr.send()
复制代码

服务端代码示例: (源为 http://127.0.0.1:3000)

const server = http.createServer((req, res) => {
  res.setHeader('Access-Control-Allow-Origin', 'http://127.0.0.1:3001') // 必填：接受域的请求
  res.setHeader('Set-Cookie', ['type=muyy']) // 下发 cookie
  res.setHeader('Access-Control-Allow-Credentials', true) // ② 选填：是否容许浏览器传 cookie 到服务端，只能设置为 true
  res.end('date from cors')
})
复制代码

至此介绍了几个比较关键 HTTP 头在 CORS 中的实践运用，更为详细的资料能够参阅 Cross-Origin Resource Sharing，最后归纳下 CORS 的优缺点，优势是支持全部类型的 HTTP 方法，缺点是有些老的浏览器不支持 CORS。

hash + iframe

在文章最开始提到过 iframe 标签也是不受同源策略限制的标签之一，hash + iframe 的跨域核心思想就是，在 A 源中经过动态改变 iframe 标签的 src 的哈希值，在 B 源中经过 window.onhashchange 来捕获到相应的哈希值。思路不难直接上代码：

A 页面代码示例(源为 http://127.0.0.1:3000)

<body>
  <iframe src="http://127.0.0.1:3001"></iframe>
  <script> const iframe = document.getElementsByTagName('iframe')[0] iframe.setAttribute('style', 'display: none') const obj = { data: 'hash' } iframe.src = iframe.src + '#' + JSON.stringify(obj) // ① 关键语句 </script>
</body>
复制代码

B 页面代码示例(源为 http://127.0.0.1:3001)

window.onhashchange = function() { // ① 关键语句
  console.log('来自 page2 的代码 ' + window.location.hash) // 来自 page2 的代码 #{"data":"hash"}
}
复制代码

刷新 A 页面，能够发如今控制台打印了以下字段，至此实现了跨域。

来自 page2 的代码 #{"data":"hash"}
复制代码

这种方式进行跨域优势是支持页面和页面间的通讯，缺点也是只支持 GET 方法和单向的跨域通讯。

postMessage

为了实现跨文档传送(cross-document messaging)，简称 XDM。HTML5 给出了一个 api —— postMessage，postMessage() 方法接收两个参数：发送消息以及消息接收方所在域的字符串。代码示例以下:

A 页面代码示例(源为 http://127.0.0.1:3000)

<body>
  <iframe src="http://127.0.0.1:3001"></iframe>
  <script> const iframe = document.getElementsByTagName('iframe')[0] iframe.setAttribute('style', 'display: none') iframe.onload = function() { // 此处要等 iframe 加载完毕，后续代码才会生效 iframe.contentWindow.postMessage('a secret', 'http://127.0.0.1:3001') } </script>
</body>
复制代码

B 页面代码示例(源为 http://127.0.0.1:3001)

window.addEventListener('message', function(event) {
  console.log('From page1 ' + event.data)
  console.log('From page1 ' + event.origin)
}, false)
复制代码

刷新 A 页面，能够发如今控制台打印了以下字段，至此实现了跨域。

From page1 a secret
From page1 http://127.0.0.1:3000
复制代码

这种跨域方式优势是是支持页面和页面间的双向通讯，缺点也是只能支持 GET 方法调用。

WebSockets

WebSockets 属于 HTML5 的协议，它的目的是在一个持久链接上创建全双工通讯。因为 WebSockets 采用了自定义协议，因此优势是客户端和服务端发送数据量少，缺点是要额外的服务器。基础的使用方法以下：

const ws = new WebSocket('ws://127.0.0.1:3000')
ws.onopen = function() {
  // 链接成功创建
}

ws.onmessage = function(event) {
  // 处理数据
}

ws.onerror = function() {
  // 发生错误时触发，链接中断
}

ws.onclose = function() {
  // 链接关闭时触发
}
复制代码

固然通常咱们会使用封装好 WebSockets 的第三方库 socket.io，这里具体就不展开了。

项目地址

前文所述五种跨域实践的 demo 已上传至 cross-domain，前端环境基于 create-react-app 搭建，后端环境用 node 搭建。

固然跨域方式还有一些其余方式的实现，后续酌情慢慢填坑~