共计 19154 个字符，预计需要花费 48 分钟才能阅读完成。
一、什么是跨域？
什么是同源策略及其限制内容？
同源策略
同源策略是一种约定，它是浏览器最核心也是最基本的安全功能，如果缺少了同源策略，浏览器很容易受到 XSS、CSFR 等攻击。所谓同源是指“协议 + 域名 + 端口”三者相同，即便两个不同的域名指向同一个 IP 地址，也非同源。
同源策略限制内容
如果非同源，下面三种行为会受到限制：
- Cookie、LocalStorage、IndexedDB 等存储性内容，无法读取
- DOM 节点，无法获得
- AJAX 请求发送后，数据被浏览器拦截
但是有三个标签是允许跨域加载资源：
<img src=“”/>
<link href=“”>
<script src=“”>常见跨域场景
当协议、域名、端口号中任意一个不同时，都算做不同域。不同域之间请求资源，就算做跨域。常见的跨域场景：
需要说明的是：
第一，如果是协议和端口造成的跨域问题，前台是无能为力的。
第二，在跨域问题上，仅仅是通过“URL 首部”来识别而不会根据域名对应的 IP 地址是否相同来判断。“URL 首部”指的就是协议，域名和端口号
注意，跨域并不是请求发不出去，请求能发出去，服务端能就收到请求并正常返回结果，只是结果被浏览器拦截了。你可能会疑问明明通过表单的方式可以发起跨域请求，为什么 Ajax 就不会？因为归根结底，跨域是为了阻止用户读取到另一个域名下的内容，Ajax 可以获取响应，但浏览器认为这个不安全，所以拦截了响应。但是表单并不会获取新的内容，所以可以发起跨域请求。这也说明了跨域并不能完全阻止 CSRF，因为请求毕竟是发出去了。
ajax 跨域的表现
我们如何根据浏览器的表现来分析是否是出现跨域问题呢？ajax 请求时，如果存在跨域现象，并且没有进行解决，会有如下表现：
第一种现象，浏览器输出错误提示 No ‘Access-Control-Allow-Origin’ header is present on the requested resource，并且 The response had HTTP status code 404。
出现这种情况的原因如下：
- 本次 ajax 请求是“非简单请求”(CORS 部分介绍)，所以请求前会发送一次预检请求（OPTIONS）
- 服务器端后台接口没有允许 OPTIONS 请求，导致无法找到对应接口地址
解决方案：后端允许 options 请求
第二种现象，浏览器输出错误提示 No ‘Access-Control-Allow-Origin’ header is present on the requested resource，并且 The response had HTTP status code 405。
这种现象与第一种有区别，这种情况下，后台方法允许 OPTIONS 请求，但是一些配置文件中（如安全配置），阻止了 OPTIONS 请求，才会导致这个现象。
解决方案：后端关闭对应的安全配置
第三种现象，浏览器输出错误提示 No ‘Access-Control-Allow-Origin’ header is present on the requested resource，并且 status 200。
这种情况下，服务器端后台允许 OPTIONS 请求，并且接口也允许 OPTIONS 请求，但是头部匹配时出现不匹配现象。比如，origin 头部检查不匹配或者少了一些头部的支持（如常见的 X -Requested-Width 头部），然后服务器端就会将 response 返回给前端，前端检测到这个后就触发 XHR。onerror，导致前端控制台报错。
解决方案：后端增加对应的头部支持
第四种现象，浏览器输出错误提示 header contains multiple values ‘,’。
表现现象是，后台响应的 http 请求头部信息有两个 Access-Control-Allow-Origin：*。出现这种问题的原因就是进行跨域配置的人不了解原理，导致了重复配置，如：
- 常见于.net 后台（一般在 web.config 中配置了一次 origin，然后代码中又手动添加了一次 origin，比如代码手动设置了返回 *）
- 常见于.net 后台（在 IIS 和项目的 web.config 中同时设置 origin:*）
解决方案：建议删除手动添加的 以及 IIS 中设置的，只用项目配置中的即可
二、Ajax 同源请求
AJAX 这个词 2005 年 2 月正式提出，它是 Asynchronous JavaScript and XML 的缩写，是指通过 javascript 的异步通信，从服务器获取 XML 文档从中提取数据，再更新当前网页的对应部分，而不用刷新整个页面。现在服务器返回的都是 JSON 格式，XML 格式已经过时了，但是 AJAX 这个叫法已经成了一个通用名字，不再是字面含义。
AJAX 包括以下几个步骤：
- 创建 XMLHttpRequest 实例
- 发出 http 请求
- 接收服务器传回的数据
- 更新网页数据
// 建立 XMLHttpRequest 对象 因为 ajax 和后台沟通是靠发 HTTP 请求来实现的
var xhr = new XMLHttpRequest();
// 指定通信过程中状态改变时的回调函数
xhr.onreadystatechange = function(){
// 具体的过程是：readyState 是 XMLHttpRequest 请求当前所处的状态，状态有五个值。当等于 4 的时候说明服务器已经完全接收了。// 通信成功时，状态值为 4
// 每当这个状态有变化的时候，readyState 的值就会变，每次变就会触发 readystatechange 这个事件，紧接着这个事件就会调用
if ((xhr.status >= 200 && xhr.status < 300) || (xhr.status === 304)){
// 这个回调函数。（第三行的函数）if (xhr.status === 200){
// 一句话总结就是：XMLHttpRequest 的状态变，导致 readyState 变，readyState 变触发 readystatechaneg 这个事件，这个事件调用回调函数
console.log(xhr.responseText);
// 好好品味这句话：xhr.onreadystatechange=function(){}, 核心点是：给 xhr 添加了一个 readystatechange 事件。事件调用了函数
} else {console.error(xhr.statusText);
}
}
};
xhr.onload = function () {
// 返回 http://example.com/test
console.log(xhr.responseURL);
};
xhr.onabort = function () {console.log('The request was aborted');
};
xhr.onprogress = function (event) {console.log(event.loaded);
console.log(event.total);
};
xhr.onerror = function (e) {console.error(xhr.statusText);
};
// 超时
xhr.ontimeout = function () {console.error('The request for' + url + 'timed out.');
};
// open 方式用于指定 HTTP 动词、请求的网址、是否异步
xhr.open('GET', '/endpoint', true);
xhr.responseType = 'text';
// 指定 10 秒钟超时
xhr.timeout = 10 * 1000;
xhr.withCredentials = true; // 跨域请求时，用户信息（比如 Cookie 和认证的 HTTP 头信息）会包含在请求之中
// 发送 HTTP 请求
xhr.send(null); // 参数可选，当参数为空时，表示请求不带参数，也可以携带参数
// 上面请求方式等同于
var data =‘id=3&time=2333';
xhr.open('GET', '/endpoint', true);
xhr.send(data);XMLHttpRequest.readyState
返回一个整数，表示当前实例对象的状态，该属性只读。有以下几种取值：
- 0，表示 XMLHttpRequest 的实例对象已经生成但是实例的 open()方法还没有被调用。
- 1，表示 open()方法已经调用，但是 send()方法还没有被调用。仍然可以使用 setRequestHeader()，设置 http 请求的头信息。
- 2，表示实例的 send()方法已经调用，并且服务器返回的头信息和状态码已经收到。
- 3，表示正在接受服务器传来的消息体（body 部分）。这时，如果实例的 responseType 属性等于 text 或者空字符串，responseType 属性就会包含已经收到的部分信息。
- 4，表示服务器发送的数据已经完全接收，或者本次接收已经失败。
通信过程中，每当实例对象发生状态变化，它的 readyState 属性的值就会发生变化。这个值每一次变化，都会触发 readyStateChange 事件。
XMLHttpRequest.onreadystatechange 属性指向一个监听函数。readystatechange 事件发生时（实例的 readyState 属性变化），就会执行这个属性。
XMLHttpRequest.responseType
该属性是一个字符串，表示服务器返回数据的类型。这个属性是可写的，可以在调用 open()方法之后，调用 send()方法之前，设置这个属性的值，告诉服务器返回指定类型数据。如果 responseType 设置为空字符串，等同于默认值 text。
- “”（空字符串），等同于 text，表示服务器返回文本数据
- “arraybuffer”，ArrayBuffer 对象，表示服务器返回二进制数组，可以按照数组的方式处理二进制数据。
- “blob”，Blob 对象，表示服务器返回二进制对象，适合读取二进制数据，比如图片文件
- “document”，Document 对象，表示服务器返回一个文档对象，适合返回 HTML/XML 文档的情况
- “json”，JSON 对象，浏览器自动对返回数据调用 JSON.parse()方法，获得一个 json 对象
- “text”，字符串
XMLHttpRequest.response
服务器返回的数据体（即 http 响应的 body 部分）。它的数据类型由 responseType 决定。只读。
XMLHttpRequest.responseURL
表示发送数据的服务器的地址。注意，这个值与 open()方法指定的请求网址不一定相同。如果服务器端发生跳转，这个属性返回最后实际返回数据的网址。另外，如果原始 URL 包括锚点，该属性会把锚点剥离。
XMLHttpRequest.status，XMLHttpRequest.statusText
表示服务器响应的 HTTP 状态码。一般来说，如果通信成功的话，状态码是 200；如果服务器没有返回状态码，那么这个属性默认是 200。请求发出之前，该属性为 0。只读。
- 200,OK，访问正常
- 301, Moved Permanently，永久移动
- 302, Move temporarily，暂时移动
- 304, Not Modified，未修改
- 307, Temporary Redirect，暂时重定向
- 401, Unauthorized，未授权
- 403, Forbidden，禁止访问
- 404, Not Found，未发现指定网址
- 500, Internal Server Error，服务器发生错误
XMLHttpRequest.timeout
表示多少毫秒后，如果请求仍然没有得到结果，就会自定终止。如果该属性等于 0，就表示没有时间限制。
事件监听属性
XMLHttpRequest 可以对以下事件指定监听函数：
- XMLHttpRequest.onloadstart：loadstart 事件（HTTP 请求发出）的监听函数
- XMLHttpRequest.onprogress：progress 事件（正在发送和加载数据）的监听函数
progress 事件的监听函数有一个事件对象参数，该对象有三个属性：loaded 属性返回已经传输的数据量，total 属性返回总的数据量，lengthComputed 属性返回一个布尔值，表示加载的进度是否可以计算。 - XMLHttpRequest.onabort：abort 事件（请求中止，比如用户调用了 abort()方法）的监听函数
- XMLHttpRequest.onerror：error 事件（请求失败）的监听函数
- XMLHttpRequest.onload：load 事件（请求成功完成）的监听函数
- XMLHttpRequest.ontimeout：timeout 事件（用户指定的时限超过了，请求还未完成）的监听函数
- XMLHttpRequest.onloadend：loadend 事件（请求完成，不管成功或失败）的监听函数
XMLHttpRequest.withCredentials
是一个布尔值，表示跨域请求时，用户信息（比如 cookie 和认证的 http 头信息）是否被包含在请求中。默认为 false，即发起跨域请求时，不会发送本机的 cookie。
若需要跨域 AJAX 请求发送 cookie，就要将 withCredentials 设置为 true。注意，同源的请求不需要设置这个属性。
为了让这个属性生效，服务器也必须显示的返回 Access-Control-Allow-Credentials 这个头部信息。
withCredentials 属性打开的话，跨域请求不仅会发送 Cookie，还会设置远程主机指定的 Cookie。反之也成立，如果 withCredentials 属性没有打开，那么跨域的 AJAX 请求即使明确要求浏览器设置 Cookie，浏览器也会忽略。
三、跨域解决方案
1、JSONP
JSONP 解决跨域问题是一个比较古老的方案，实际中不推荐使用，如果在项目中要使用 JSONP，一般会使用 JQ 等对 JSONP 进行了封装的类库来进行 ajax 请求。
实现原理
利用 script 标签没有跨域限制的漏洞，网页可以得到从其它来源动态产生的 JSON 数据。JSONP 请求一定需要对方服务器做支持才可以。具体原理如下：
实现流程
- 声明一个回调函数，其函数名（如 foo）当作参数值，要传递给跨域请求数据的服务器，函数形参为要获取目标数据（服务器返回的 data）
- 创建一个 script 标签，把那个跨域的 API 数据接口地址复制给 script 的 src，还要在这个地址中向服务器传递函数名（可以通过问号传参?callback=show）
- 服务器接收到请求后，需要进行特殊的处理：把传递进来的函数名和它需要给你的数据拼接成字符串，例如：传入的函数名是 foo，它准备好的数据是 foo(‘爱你哟！’)
- 最后服务器把准备的数据通过 HTTP 协议返回给客户端，客户端再调用执行之前声明的回调函数（foo）
在开发中可能会遇到多个 JSONP 请求的回调函数名是相同的，这时候就需要自己封装一个 JSONP 函数。下面这段代码相当于向 http://localhost:3000/say?wd=Iloveyou&callback=foo 这个请求地址请求数据，然后后台返回 foo(‘爱你呦！’)，最后会运行 foo()这个函数。
注意，JSONP 接口和普通接口返回数据是有区别的，接口在兼容 JSONP 请求的时候需要判断是否有对应关键字 callback 参数。
//index.html
function jsonp({url, params, callback}) {return new Promise((resolve, reject) => {let script = document.createElement('script’);
window[callback] = function(data) {resolve(data);
document.body.removeChild(script);
};
params = {...params, callback}; // wd=Iloveyou&callback=foo
let arrs = [];
for (let key in params) {arrs.push(`${key}=${params[key]}`);
}
script.src = `${url}?${arrs.join('&')}`;
document.body.appendChild(script);
})
}
jsonp({
url: 'http://localhost:3000/say',
params: {wd: 'Iloveyou'},
callback:‘foo'
}).then(data => {console.log(data);
})
//server
let express = require('express’);
let app = express();
app.get('/say', function(req, res) {let { wd, callback} = req.query;
console.log(wd); // Iloveyou
console.log(callback); // foo
res.end(`${callback}('我不爱你')`);
})
app.listen(3000);JSONP 优缺点
JSONP 优点是兼容性好，可用于解决主流浏览器的跨域数据访问的问题。缺点是仅支持“get”请求，不支持较为复杂的 POST 和其它请求。
2、CORS
CORS 是一个 W3C 标准，全称是“跨域资源共享”（Cross-origin resource sharing）。它允许浏览器向跨源服务器发出 XMLHttpRequest 请求，从而克服了 Ajax 只能同源使用的限制。目前几乎所有的浏览器 ajax 请求都是基于 CORS 机制的。
CORS 需要浏览器和服务器同时支持。目前，所有浏览器都支持该功能，IE 浏览器不能低于 IE10。
整个 CORS 的通信过程都是浏览器自动完成，不需要用户参与。对于开发者来说，CORS 通信与同源的 Ajax 通信没有差别，代码完全一样。浏览器发现 AJAX 请求跨域，会自动添加一些头信息，有时还会多出一次附加的请求，但用户不会有感觉。
两种请求
浏览器将 CORS 请求分为两类：简单请求（simple request）和非简单请求（no-so-simple request）。
如何判断请求的类型？
只要同时满足这两大条件，就属于简单请求。
- 请求方法是以下三种方法之一：HEAD、GET、POST
-
HTTP 的头信息不超过以下几个字段：
- Accept
- Accept-Language
- Content-Language
- Last-Event-ID
- Content-Type，只限于三个值：application/x-www-form-urlencoded、multipart/form-data、text/plain
简单请求
对于简单请求，浏览器直接发出 CORS 请求。具体来说，浏览器发现这次跨源 AJAX 请求是简单请求，就自动在头信息中添加一个 Origin 字段，Origin 字段用来说明本次请求来自哪个源（协议 + 域名 + 端口）。服务器根据这个值，决定是否同意这次请求。
- 如果 Origin 指定的源不在许可范围内，服务器会返回一个正常的 HTTP 响应。但是浏览器发现回应头信息中没有包含 Access-Control-Allow-Origin 字段，就知道出错了，然后抛出一个错误，被 XMLHttpRequest 的 onerror 捕获。这种错误是无法通过状态码识别，因为 HTTP 回应的状态码可能是 200.
-
如果 Origin 指定的域名在许可范围内，服务器响应的头信息会增加几个以 Access-Control- 开头的头信息字段：
- Access-Control-Allow-Origin
该字段是必须的，它的值要么是请求时 Origin 字段的值，要么是一个 *，表示接受任意域名的请求。 - Access-Control-Allow-Credentials
该字段可选。它的值是一个布尔值，表示是否允许发送 cookie。默认情况下，cookie 不包含在 CORS 请求中。设为 true 即表示服务器明确许可 cookie 可以包含在请求中，一起发给服务器。
这个值只能设为 true，如果服务器不需要浏览器发送 cookie，删除该字段即可。 - Access-Control-Allow-Headers
该字段可选。CORS 请求时，XMLHttpRequest 对象的 getResponseHeader()方法只能拿到 6 个基本字段：Cache-Control、Content-Language、Content-Type、Expires、Last-Modified、Pragma。如果想拿到其他字段，就必须在 Access-Control-Headers 中指定。例如 getResponseHeader(’token’).
- Access-Control-Allow-Origin
widthCredentials
该属性在同源 AJAX 请求中已经介绍了，这里再做些补充。
上面说到，CORS 请求默认是不发送用户信息，如果要不 Cookie 发到服务器，除了服务器设置 Access-Control-Allow-Credentials：true 外，开发者也要在 AJAX 请求中打开 withCredentials 属性，xhr.withCredentials=true。
否则即使服务器同意发送 Cookie，浏览器也不会发送。或者，服务器要求设置 Cookie，浏览器也不会处理。
如果省略设置 withCredentials，有的浏览器也会在请求时发送 Cookie。此时，可以显示的关闭 withCredentials，xhr.withCredentials=false。
注意
- 如果要发送 Cookie，Access-Control-Allow-Origin 就不能设为星号，必须指定明确的、与请求网页一致的域名。
- Cookie 依然遵循同源政策，只有用服务器域名设置的 Cookie 才会上传，其它域名的 Cookie 并不会上传，且（跨源）原网页中的 document.cookie 也无法读取服务器域名下的 cookie
非简单请求
非简单请求是那种对服务器有特殊要求的请求，比如请求方法是 PUT 或 DELETE，或者 Content-Type 字段的类型是 application/json。
预检请求
非简单请求的 CORS 请求，会在正式通信前，增加一次 HTTP 查询请求，称为“预检”请求（preflight），如上图左。
浏览器先询问服务器，当前网页所在的域名是否在服务器的许可名单之中，以及可以使用那些 HTTP 动词和头信息字段。只有得到肯定答复，浏览器才会发出正式的 XMLHttpRequest 请求，否则就报错。
预检请求用的请求方法是 OPTIONS，表示这个请求是用来询问的。请求的头信息里包含关键字段 Origin，表示请求来自哪个源。除了 Origin 字段，预检请求的头信息包括两个特殊字段：
- Access-Control-Request-Method，该字段是必须的，用来列出浏览器的 CORS 请求会用到哪些 HTTP 方法上，图中是 POST
- Access-Control-Request-Headers，该字段是一个逗号分隔的字符串，指定浏览器 CORS 请求额外发送的头信息字段，图中是 content-type,token,x-requested-with
预检请求的响应
服务器接到预检请求后，检查 Origin，Access-Control-Request-Method，Access-Control-Request-Headers 字段后，确认允许跨源请求，就可以做出响应，如图左 Response Headers。
这个响应部分的关键字段就是 Access-Control-Allow-Origin，图中表示 http://192.168.6.164:8084 可以请求数据。该字段也可以设置为 *，表示同意任意跨源请求。
如果服务器否定了预检请求，会正常返回一个 HTTP 响应，但是没有任何 CORS 相关的头信息字段。这时浏览器在检查时就会认为服务器不同意预检请求，抛出错误被 XMLHttpRequest 对象的 onerror 函数捕获并打印错误。
服务器在允许跨源请求时，预检响应头返回的几个 CORS 相关字段：
- Access-Control-Allow-Origin，必需，允许请求数据的源
- Access-Control-Allow-Methods，必需，它是逗号分隔的一个字符串，表明服务器支持的所有跨域请求方法。注意，返回的是所有支持的方法，而不是单一的浏览器请求的那个方法，为了避免多次“预检”请求。
- Access-Control-Allow-Headers，如果请求中包含 Access-Control-Request-Headers 字段，则相应中该字段就是必需的。它是逗号分隔的字符串，表明服务器支持的所有头信息字段，但不限于预检请求中的字段
- Access-Control-Allow-Credentials，与简单请求中的含义相同
- Access-Control-Max-Age，可选，用来指定本次预检请求的有效期，单位为秒。在有效期内，不需要发出另一条预检请求。
浏览器的正常请求和响应
如上图右，浏览器预检通过后，浏览器正常的 CORS 请求就都跟简单请求一样。在请求头中浏览器会自动添加 Origin 字段，在服务器响应中，也必包含 Access-Control-Allow-Origin 字段。
与 JSONP 的比较
CORS 和 JSONP 的使用目的相同，但是比 JSONP 更强大。
JSONP 只支持 GET 请求，CORS 支持所有类型的 HTTP 请求。JSONP 的优势在于支持老式浏览器，以及可以向不支持 CORS 的网站请求数据。
3、postMessage
postMessage 是 HTML5 XMLHttpRequest Level 2 中的 API，且是为数不多的可以跨域操作的 window 属性之一，它可以解决以下几个方面的内容：
- 页面和其打开的新窗口的数据传递
- 多窗口之间消息传递
- 页面与嵌套的 iframe 消息传递
- 上面三个场景的跨域数据传递
postMessage() 方法允许来自不同源的脚本采用异步方式进行有限的通信，可是实现跨文本档、多窗口、跨域消息传递。
语法
otherWindow.postMessage(message, targetOrigin, [transfer]);
- otherWindow
其它窗口的一个引用，比如 iframe 的 contentWindow 属性、执行 window.open 返回的窗口对象、或者是命名过或数值索引的 window.iframes。 - message
将要发送到其它 window 的数据 - targetOrigin
通过窗口的 origin 属性来指定哪些窗口能接收到消息事件，其值可以是字符串“*”或者一个 URI。在发送消息时，如果协议、主机地址或者端口号这三者中有任意一项不匹配 targetOrigin 提供的值，那么消息就不会被发送，只有三者完全匹配时消息才会发送。
这样做的目的是防止数据泄漏。例如，当 postMessage 传递密码时，targetOrigin 的值与包含这个密码的消息的预期接受者的 origin 属性完全一致，来防止密码被恶意的第三方截获。如果明确的知道接受方的 URI，就不要设置为 *。 - transfer(可选)
是一串和 message 同时传递的 transferable 对象。这些消息的所有权将移交给消息的接受者，发送方将不再保有所有权。
安全问题
- 如果不希望从其他网站接收 message，请不要为 message 事件添加任何事件监听器。这是一个安全万无一失的方式来避免安全问题。
- 如果确实需要从其他网站接收 message，请始终使用 origin 和 source 属性验证发件人的身份。任何窗口都可以向任何其他窗口发送消息，并且不能保证未知发送者不发送恶意信息。但是，身份验证后，仍然需要始终验证接收到的消息的语法。否则，您信任只发送受信任邮件的网站中的安全漏洞可能会在您的网站中打开跨网站脚本漏洞。
- 当使用 postMessage 将数据发送到其它窗口时，始终指定精确的 Origin，而不是 *。恶意网站可以在你不知情的情况下更改窗口的位置，因此它可以拦截使用 postMessage 发送的数据。
兼容性
几乎所有新版浏览器，IE8+ 都支持。但是有些浏览器的低版本不支持（例如 FireFox 4.0）
示例
/*
* A 窗口的域名是 <http://example.com:8080>，以下是 A 窗口的 script 标签下的代码：*/
var popup = window.open(...popup details...);
// 如果弹出框没有被阻止且加载完成
// 这行语句没有发送信息出去，即使假设当前页面没有改变 location（因为 targetOrigin 设置不对）popup.postMessage("The user is'bob'and the password is'secret'","https://secure.example.net");
// 假设当前页面没有改变 location，这条语句会成功添加 message 到发送队列中去（targetOrigin 设置对了）popup.postMessage("hello there!", "http://example.org");
function receiveMessage(event)
{// 我们能相信信息的发送者吗? (也许这个发送者和我们最初打开的不是同一个页面).
if (event.origin !== "http://example.org")
return;
// event.source 是我们通过 window.open 打开的弹出页面 popup
// event.data 是 popup 发送给当前页面的消息 "hi there yourself! the secret response is: rheeeeet!"
}
window.addEventListener("message", receiveMessage, false);
/*
* 弹出页 popup 域名是 <http://example.org>，以下是 script 标签中的代码:
*/
// 当 A 页面 postMessage 被调用后，这个 function 被 addEventListenner 调用
function receiveMessage(event)
{
// 我们能信任信息来源吗？if (event.origin !== "http://example.com:8080")
return;
// event.source 就当前弹出页的来源页面
// event.data 是 "hello there!"
// 假设你已经验证了所受到信息的 origin (任何时候你都应该这样做), 一个很方便的方式就是把 enent.source
// 作为回信的对象，并且把 event.origin 作为 targetOrigin
event.source.postMessage("hi there yourself! the secret response" +
"is: rheeeeet!",
event.origin);
}
window.addEventListener("message", receiveMessage, false);
// a.html
<iframe src="http://localhost:4000/b.html" frameborder="0" id="frame" onload="load()"></iframe// 等它加载完触发一个事件
// 内嵌在 http://localhost:3000/a.html
<script>
function load() {let frame = document.getElementById('frame')
frame.contentWindow.postMessage('我爱你', 'http://localhost:4000') // 发送数据
window.onmessage = function(e) { // 接受返回数据
console.log(e.data) // 我不爱你
}
}
</script>
// b.html
window.onmessage = function(e) {console.log(e.data) // 我爱你
e.source.postMessage('我不爱你', e.origin)
}4、websocket
WebSocket 是 HTML5 开始提供的一种在单个 TCP 连接上进行全双工通讯的协议。
WebSocket 使得客户端和服务器之间的数据交换变得更加简单，允许服务端主动向客户端推送数据。在 WebSocket API 中，浏览器和服务器只需要完成一次握手，两者之间就直接可以创建持久性的连接，并进行双向数据传输。
为了建立一个 WebSocket 连接，客户端浏览器首先要向服务器发起一个 HTTP 请求，这个请求和通常的 HTTP 请求不同，包含了一些附加头信息，其中附加头信息 ”Upgrade: WebSocket” 表明这是一个申请协议升级的 HTTP 请求，服务器端解析这些附加的头信息然后产生应答信息返回给客户端，客户端和服务器端的 WebSocket 连接就建立起来了，双方就可以通过这个连接通道自由的传递信息，并且这个连接会持续存在直到客户端或者服务器端的某一方主动的关闭连接。
var Socket = new WebSocket(url, [protocol] );
第一个参数 URL 是指定连接的 url，第二个参数 protocol 是可选的，制定了可接受的子协议。
// socket.html
<div>user input：<input type="text"></div>
<script src="./socket.io.js"></script>
<script>
var socket = io('http://www.domain2.com:8080');
// 连接成功处理
socket.on('connect', function() {
// 监听服务端消息
socket.on('message', function(msg) {console.log('data from server: --->' + msg);
});
// 监听服务端关闭
socket.on('disconnect', function() {console.log('Server socket has closed.');
});
});
document.getElementsByTagName('input')[0].onblur = function() {socket.send(this.value);
};
</script>
//Nodejs socket 后台：var http = require('http');
var socket = require('socket.io');
// 启 http 服务
var server = http.createServer(function(req, res) {
res.writeHead(200, {'Content-type': 'text/html'});
res.end();});
server.listen('8080');
console.log('Server is running at port 8080...');
// 监听 socket 连接
socket.listen(server).on('connection', function(client) {
// 接收信息
client.on('message', function(msg) {client.send('hello：' + msg);
console.log('data from client: --->' + msg);
});
// 断开处理
client.on('disconnect', function() {console.log('Client socket has closed.');
});
});5、Node 中间件代理（两次跨域）
实现原理
同源策略是浏览器需要遵循的标准，而如果服务器向服务器请求就无需遵循同源策略。
代理服务器需要做以下步骤：
- 接收客户端请求
- 将请求转发给服务器
- 拿到服务器响应数据
- 将响应转发给客户端
以下实例经过两次跨域，浏览器向代理服务器发送请求时，也遵循同源策略。
// index.html(http://127.0.0.1:5500)
<script src="https://cdn.bootcss.com/jquery/3.3.1/jquery.min.js"></script>
<script>
$.ajax({
url: 'http://localhost:3000',
type: 'post',
data: {name: 'xiamen', password: '123456'},
contentType: 'application/json;charset=utf-8',
success: function(result) {console.log(result) // {"title":"fontend","password":"123456"}
},
error: function(msg) {console.log(msg)
}
})
</script>
// server1.js 代理服务器(http://localhost:3000)
const http = require('http')
// 第一步：接受客户端请求
const server = http.createServer((request, response) => {
// 代理服务器，直接和浏览器直接交互，需要设置 CORS 的首部字段
response.writeHead(200, {
'Access-Control-Allow-Origin': '*',
'Access-Control-Allow-Methods': '*',
'Access-Control-Allow-Headers': 'Content-Type'
})
// 第二步：将请求转发给服务器
const proxyRequest = http
.request(
{
host: '127.0.0.1',
port: 4000,
url: '/',
method: request.method,
headers: request.headers
},
serverResponse = {
// 第三步：收到服务器的响应
var body = ''serverResponse.on('data', chunk => {body += chunk})
serverResponse.on('end', () => {console.log('The data is' + body)
// 第四步：将响应结果转发给浏览器
response.end(body)
})
}
)
.end()})
server.listen(3000, () => {console.log('The proxyServer is running at http://localhost:3000')
})
// server2.js(http://localhost:4000)
const http = require('http')
const data = {title: 'fontend', password: '123456'}
const server = http.createServer((request, response) => {if (request.url === '/') {response.end(JSON.stringify(data))
}
})
server.listen(4000, () => {console.log('The server is running at http://localhost:4000')
})6、nginx 反向代理
实现原理类似于 node 中间件代理，需要搭建一个中转 nginx 服务器，用于转发请求。
使用 nginx 反向代理实现跨域，是最简单的跨域方式。只需要修改 nginx 的配置即可解决跨域问题，支持所有浏览器，支持 session，不需要修改任何代码，并且不影响服务器性能。
实现思路：通过 nginx 配置一个代理服务器（域名和 domain1 相同，端口不同）做跳板机，反向代理访问 domain2 接口，并且可以顺便修改 cookie 中的 domain 信息，方便当前域 cookie 写入，实现跨域登录。
// proxy 服务器
server {
listen 80;
server_name www.domain1.com;
location / {
proxy_pass http://www.domain2.com:8080; #反向代理
proxy_cookie_domain www.domain2.com www.domain1.com; #修改 cookie 里域名
index index.html index.htm;
# 当用 webpack-dev-server 等中间件代理接口访问 nignx 时，此时无浏览器参与，故没有同源限制，下面的跨域配置可不启用
add_header Access-Control-Allow-Origin http://www.domain1.com; #当前端只跨域不带 cookie 时，可为 *
add_header Access-Control-Allow-Credentials true;
}
}7、window.name+iframe
window.name 属性的独特之处：name 值在不同的页面（甚至不同域名）加载后依旧存在，并且可以支持非常长的 name 值（2MB）。
以下例子中，onload 事件会被触发两次：
- 第一次加载跨域页 c.html，c.html 页面设置了 window.name 的值。页面加载完成后触发 onload 事件，调用 load 方法，重新设置了 iframe 窗口的 src 值，这时会产生第二次页面加载
- b.html 加载完成后触发第二次 onload 事件，此时 iframe 窗口中已经留有打开 c.html 页面时设置的 window.name 值，这个值就可以在代码中读取到
// a.html(http://localhost:3000/b.html)
// b 为中间代理页，内容为空
<iframe src="http://localhost:4000/c.html" frameborder="0" onload="load()" id="iframe"></iframe>
<script>
let first = true;
let iframe = document.getElementById('iframe');
// onload 事件会触发 2 次，第 1 次加载跨域页，并留存数据于 window.name
function load() {if(first){// 第 1 次 onload(跨域页)成功后，切换到同域代理页面
iframe.src = 'http://localhost:3000/b.html';
first = false;
}else{// 第 2 次 onload(同域 b.html 页)成功后，读取同域 window.name 中数据
console.log(iframe.contentWindow.name);
}
}
</script>
// c.html(http://localhost:4000/c.html)
<script>
window.name = '我不爱你'
</script>8、location.hash+iframe
实现原理：a.html 欲与 c.html 跨域相互通信，通过中间页 b.html 来实现。三个页面，不同域之间利用 iframe 的 location.hash 传值，相同域之间直接 js 访问来通信。
实现步骤：一开始 a.html 给 c.html 传一个 hash 值，然后 c.html 接收到 hash 值后，再把 hash 值传给 b.html，最后 b.html 将结果放到 a.html 的 hash 值中
以下例子，a.html 和 b.html 是同域的，而 c.html 是跨域的
// a.html
<iframe src="http://localhost:4000/c.html#iloveyou"></iframe>
<script>
window.onhashchange = function () { // 检测 hash 的变化
console.log(location.hash);
}
</script>
// b.html
<script>
window.parent.parent.location.hash = location.hash
//b.html 将结果放到 a.html 的 hash 值中，b.html 可通过 parent.parent 访问 a.html 页面
</script>
// c.html
console.log(location.hash);
let iframe = document.createElement('iframe');
iframe.src = 'http://localhost:3000/b.html#idontloveyou';
document.body.appendChild(iframe);9、document.domain+iframe
该方式只适用于二级域名相同的情况下，比如 a.test.com 和 b.test.com 适用于此方式。
实现方式：只需要给页面添加 document.domain =‘test.com’，表示二级域名都相同就可以实现跨域。
实现原理：两个页面都通过 js 强制设置了 document.domain 为基础主域，就实现了同域。
// a.html
<body>
hello，a
<iframe src="http://b.zf1.cn:3000/b.html" frameborder="0" onload="load()" id="frame"></iframe>
<script>
document.domain = 'zf1.cn'
function load() {console.log(frame.contentWindow.a);
}
</script>
</body>
// b.html
<body>
hello，b
<script>
document.domain = 'zf1.cn'
var a = 100;
</script>
</body>四、总结
- CORS 支持所有类型的 HTTP 请求，是跨域 HTTP 请求的根本解决方案
- JSONP 只支持 GET 请求，JSONP 的优势在于支持老式浏览器，以及可以向不支持 CORS 的网站请求数据
- 不管是 Node 中间件代理还是 nginx 反向代理，主要是通过同源策略对服务器不加限制
- 日常工作中，用的比较多的跨域方案是 CORS 和 nginx 反向代理
参考文献：
《九种跨域方式实现原理》浪里行舟 https://mp.weixin.qq.com/s/LV…
《ajax 跨域，这应该是最全的解决方案了》撒网要见鱼 https://segmentfault.com/a/11…
《Ajax 与 JSON 的一些总结》JKhuang http://www.cnblogs.com/rush/a…
《跨域资源共享 CORS 详解》阮一峰 http://www.ruanyifeng.com/blo…
《Ajax》http://javascript.ruanyifeng….
《postMessage》官方文档 https://developer.mozilla.org…
