【面试系列】跨域的几种解决方案为了安全，浏览器规定了同源策略，不允许跨域访问资源。也就是说如果url a 要访问 ur

跨域问题的根源

为了安全，浏览器规定了同源策略，不允许跨域访问资源。

何为同源策略？

同源策略/SOP（Same origin policy）是一种约定，由Netscape公司1995年引入浏览器，它是浏览器最核心也最基本的安全功能，如果缺少了同源策略，浏览器很容易受到XSS、CSFR等攻击。 所谓同源是指"协议+域名+端口"三者相同，即便两个不同的域名指向同一个ip地址，也非同源。

也就是说如果url a 要访问 url b，那么a和b的协议+域名+端口号三者必须一致，才能访问，否则就需要解决跨域问题。

同源策略限制了：

Cookie、LocalStorage 和 IndexDB 无法读取
DOM 和 Js对象无法获得
AJAX 请求不能发送

跨域的解决方案

目前常用的跨域解决方案主要有以下几种：

jsonp
CORS
websocket
nginx反向代理
node.js中间件
postMessage

下面我们详细介绍一下每一种方式的具体实现。

1. jsonp

jsonp的核心是动态加载js。这种方式主要是利用了script标签的src属性不受跨域影响，可以访问外部脚本文件的能力。

而拥有“src”属性，具备跨域能力的还有img和iframe标签。但由于img只能发送请求，不能接收和处理数据，iframe和当前页面通信也可能存在跨域问题，且iframe有本身会阻塞主页面加载等缺点，所以这两个标签不如script标签适合。(iframe+domain可以实现跨子域，此篇未做过多相关讨论)

jsonp方案的具体实现方式

// 动态的加载js文件
function addScript(src) {
  const script = document.createElement('script');
  script.src = src;
  script.type = "text/javascript";
  document.body.appendChild(script);
}
addScript("http://xxx.xxx.com/xxx.js?callback=handleRes");
// 设置一个全局的callback函数来接收回调结果
function handleRes(res) {
  console.log(res);
}
// xxx.js返回的数据格式
handleRes({a: 1, b: 2});

jsonp的缺点是只能实现get一种请求。

2. CORS

CORS(cross origin resource share) - 跨域资源共享，这种方案需要服务端同学的支持。

浏览器将CORS请求分为了两类：简单请求和非简单请求。

2.1 简单请求

简单请求需要同时满足以下两个条件：

请求方法是HEAD、GET、POST其中之一
HTTP的请求头信息不超过以下几个字段
- Accept
- Accept-Language
- Content-Language
- Last-Event-ID
- Content-type：只限于application/x-www-form-urlencode、multiple/form-data、text/plain三个值

简单请求的基本流程

浏览器发现这次跨源AJAX请求是简单请求，就会自动在头信息之中，添加一个Origin字段(Origin字段用来说明，本次请求来自哪个源（协议 + 域名 + 端口）)，直接发出CORS请求。
服务器根据Origin字段，决定是否同意这次请求。如果Origin指定的源，不在许可范围内，服务器会返回一个正常的HTTP回应。如果Origin指定的域名在许可范围内，服务器返回的响应会多出以下几个头信息字段：
- Access-Control-Allow-Origin: api.bob.com
- Access-Control-Allow-Credentials: true
- Access-Control-Expose-Headers: FooBar
- Content-Type: text/html; charset=utf-8
浏览器检查服务器回应的头信息有没有包含Access-Control-Allow-Origin字段。如果没有包含Access-Control-Allow-Origin字段，浏览器就知道出错了，从而抛出一个错误，被XMLHttpRequest的onerror回调函数捕获。（注意，这种错误无法通过状态码识别，因为HTTP回应的状态码有可能是200。）

🏁️ 服务器响应字段说明：

Access-Control-Allow-Origin: 该字段是必须的。它的值要么是请求时Origin字段的值，要么是一个*，表示接受任意域名的请求。

Access-Control-Allow-Credentials: 该字段可选。它的值是一个布尔值，表示是否允许发送Cookie。默认情况下，Cookie不包括在CORS请求之中。设为true，即表示服务器明确许可，Cookie可以包含在请求中，一起发给服务器。如果要发送Cookie，Access-Control-Allow-Origin就不能设为星号，必须指定明确的、与请求网页一致的域名，且前端开发必须在AJAX请求中打开withCredentials属性（设置withCredentials为true，例如： var xhr = new XMLHttpRequest(); xhr.withCredentials = true;） Cookie依然遵循同源政策，只有用服务器域名设置的Cookie才会上传，其他域名的Cookie并不会上传，且（跨源）原网页代码中的document.cookie也无法读取服务器域名下的Cookie。Access-Control-Allow-Credentials只能设为true，如果服务器不要浏览器发送Cookie，删除该字段即可。

Access-Control-Expose-Headers: 该字段可选。CORS请求时，XMLHttpRequest对象的getResponseHeader()方法只能拿到6个基本字段：Cache-Control、Content-Language、Content-Type、Expires、Last-Modified、Pragma。如果想拿到其他字段，就必须在Access-Control-Expose-Headers里面指定。上面的例子指定，getResponseHeader('FooBar')可以返回FooBar字段的值。

2.2 非简单请求

不满足简单请求的条件的，都属于非简单请求。一般是那种对服务器有特殊要求的请求，比如请求方法是PUT或DELETE，或者Content-Type字段的类型是application/json等。

非简单请求的基本流程

非简单请求的CORS请求，浏览器会先询问服务器，当前网页所在的域名是否在服务器的许可名单之中，以及可以使用哪些HTTP动词和头信息字段。所以在正式通信之前，浏览器会增加一次HTTP查询请求，称为"预检"请求（preflight）。"预检"请求用的请求方法是OPTIONS，表示这个请求是用来询问的。请求头信息里面，关键字段是Origin，表示请求来自哪个源。

🏁 CORS预检请求头字段说明

Access-Control-Request-Method: 该字段是必须的，用来列出浏览器的CORS请求会用到哪些HTTP方法

Access-Control-Request-Headers: 该字段是一个逗号分隔的字符串，指定浏览器CORS请求会额外发送的头信息字段

服务器收到"预检"请求以后，检查了Origin、Access-Control-Request-Method和Access-Control-Request-Headers字段以后，确认是否允许跨源请求，就可以做出回应。如果服务器否定了"预检"请求，会返回一个正常的HTTP回应，但是没有任何CORS相关的头信息字段。如果服务器通过“预检”请求，就会回应的其他CORS字段。比如：
- Access-Control-Allow-Methods: GET, POST, PUT
- Access-Control-Allow-Headers: X-Custom-Header
- Access-Control-Allow-Credentials: true
- Access-Control-Max-Age: 1728000
如果浏览器没有发现响应头里面有CORS的相关字段，浏览器就会认定，服务器不同意预检请求，因此触发一个错误，被XMLHttpRequest对象的onerror回调函数捕获。控制台会打印出如下的报错信息：

XMLHttpRequest cannot load http://api.alice.com.
Origin http://api.bob.com is not allowed by Access-Control-Allow-Origin.

一旦服务器通过了"预检"请求，以后每次浏览器正常的CORS请求，就都跟简单请求一样，会有一个Origin头信息字段。服务器的回应，也都会有一个Access-Control-Allow-Origin头信息字段。

🏁 CORS服务端响应头字段说明

Access-Control-Allow-Methods: GET, POST, PUT; 该字段必需，它的值是逗号分隔的一个字符串，表明服务器支持的所有跨域请求的方法。注意，返回的是所有支持的方法，而不单是浏览器请求的那个方法。这是为了避免多次"预检"请求。

Access-Control-Allow-Headers: X-Custom-Header; 如果浏览器请求包括Access-Control-Request-Headers字段，则Access-Control-Allow-Headers字段是必需的。它也是一个逗号分隔的字符串，表明服务器支持的所有头信息字段，不限于浏览器在"预检"中请求的字段。

Access-Control-Allow-Credentials: true; 该字段与简单请求时的含义相同。

Access-Control-Max-Age: 1728000; 该字段可选，用来指定本次预检请求的有效期，单位为秒。上面结果中，有效期是20天（1728000秒），即允许缓存该条回应1728000秒（即20天），在此期间，不用发出另一条预检请求

CORS请求比jsonp更强大一点，JSONP只支持GET请求，CORS支持所有类型的HTTP请求。JSONP的优势在于支持老式浏览器，以及可以向不支持CORS的网站请求数据。

3. websocket

WebSocket protocol是HTML5一种新的协议。它实现了浏览器与服务器全双工通信，同时允许跨域通讯，能更好的节省服务器资源和带宽并达到实时通讯的目的，是server push技术的一种很好的实现。

socket本质上是对 TCP/IP 的运用进行了一层封装，应用程序直接调用 socket API 即可进行通信。

socket是如何工作的呢？

分为 2 个部分，服务端需要建立 socket 来监听指定的地址，然后等待客户端来连接。而客户端则需要建立 socket 并与服务端的 socket 地址进行连接。

WebSocket和HTTP最大不同是

WebSocket是一种双向通信协议。在建立连接后，WebSocket服务器端和客户端都能主动向对方发送或接收数据，
WebSocket需要像TCP一样，先建立连接，连接成功后才能相互通信。
一旦WebSocket连接建立后，后续数据都以帧序列的形式传输。
在客户端断开WebSocket连接或Server端中断连接前，不需要客户端和服务端重新发起连接请求。
在海量并发及客户端与服务器交互负载流量大的情况下，极大的节省了网络带宽资源的消耗，有明显的性能优势，且客户端发送和接受消息是在同一个持久连接上发起，实时性优势明显。

websocket的基本用法：

// WebSocket 协议的 URL 使用 ws://开头，另外安全的 WebSocket 协议使用 wss://开头
// 只需要实例化 WebSocket，创建连接，然后服务端和客户端就可以相互发送和响应消息
var socket = new websocket('ws://echo.websocket.org');
//当 Browser 和 WebSocketServer 连接成功后，会触发 onopen
ws.onopen = function(){ws.send(“Test!”); }; 
// 如果连接失败，发送、接收数据失败或者处理数据出现错误，会触发 onerror 
ws.onerror = function(evt){console.log(“WebSocketError!”);};
// 当 Browser 接收到 WebSocketServer 发送过来的数据时，就会触发 onmessage 消息，参数 evt 中包含 Server 传输过来的数据
ws.onmessage = function(evt){console.log(evt.data);ws.close();}; 
// 如果你想往后端推送数据，可以使用
// 因为Web Socket只能接受和发送纯为本数据，所以对数稍微复杂的数据，可以把他转化为JSON字符串
ws.send(data);
// 当 Browser 接收到 WebSocketServer 端发送的关闭连接请求时，就会触发 onclose 消息。
ws.onclose = function(evt){console.log(“WebSocketClosed!”);};

4. nginx反向代理

同源策略是浏览器的安全策略，不是HTTP协议的一部分。服务器端调用HTTP接口只是使用HTTP协议，不会执行JS脚本，没有同源策略的限制，所以不存在跨越问题。

实现思路

通过nginx配置一个代理服务器（域名与domain1相同，端口不同）做跳板机，反向代理访问domain2接口，并且可以顺便修改cookie中domain信息，方便当前域cookie写入，实现跨域登录。

nginx配置文件

#proxy服务器
server {
    listen       81;
    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;
    }
}

5. node.js中间件

node中间件实现跨域代理，原理大致与nginx相同，都是通过启一个代理服务器，实现数据的转发，也可以通过设置cookieDomainRewrite参数修改响应头中cookie中域名，实现当前域的cookie写入，方便接口登录认证。

本地开发环境的跨域问题用node做代理转发请求server（完美解决开发环境下请求server的跨域问题）。使用中间件进行跨域必须写在使用路由之前。

具体实现可以参考

var express = require('express');
var proxy = require('http-proxy-middleware');
var app = express();

app.use('/', proxy({
    // 代理跨域目标接口
    target: 'http://www.domain2.com:8080',
    changeOrigin: true,

    // 修改响应头信息，实现跨域并允许带cookie
    onProxyRes: function(proxyRes, req, res) {
        res.header('Access-Control-Allow-Origin', 'http://www.domain1.com');
        res.header('Access-Control-Allow-Credentials', 'true');
    },

    // 修改响应信息中的cookie域名
    cookieDomainRewrite: 'www.domain1.com'  // 可以为false，表示不修改
}));

app.listen(3000);
console.log('Proxy server is listen at port 3000...');

利用node + webpack + webpack-dev-server代理接口跨域。在开发环境下，由于vue渲染服务和接口代理服务都是webpack-dev-server同一个，所以页面与代理接口之间不再跨域，无须设置headers跨域信息了。

// webpack.config.js部分配置
module.exports = {
    // ...
    devServer: {
        disableHostCheck: true,
        proxy: {
            /login/ {
                target: 'http://www.domain2.com:8080',  // 代理跨域目标接口
                changeOrigin: true,
                secure: false,  // 当代理某些https服务报错时用
                cookieDomainRewrite: 'www.domain1.com'  // 可以为false，表示不修改
            }
        },
        noInfo: true
    }
}

6. postMessage

postMessage是HTML5 XMLHttpRequest Level 2中的API，且是为数不多可以跨域操作的window属性之一，它可用于解决以下三个场景的跨域数据传递：

页面和其打开的新窗口的数据传递
多窗口之间消息传递
页面与嵌套的iframe消息传递

postMessage的API

otherWindow.postMessage(message, targetOrigin, [transfer]);

otherWindow：其他窗口的一个引用，比如iframe的contentWindow属性，执行window.open返回的窗口对象，或者是命名过的或数值索引的window.frames。
message：要发送到其他窗口的数据, html5规范支持任意基本类型或可复制的对象，但部分浏览器只支持字符串，所以传参时最好用JSON.stringify()序列化。
targetOrigin：协议+主机+端口号，通过窗口的origin属性来指定哪些窗口能接收到消息事件,指定后只有对应origin下的窗口才可以接收到消息,设置为通配符"*"表示可以发送到任何窗口,但通常处于安全性考虑不建议这么做.如果想要发送到与当前窗口同源的窗口,可设置为"/"
transfer：可选属性，是一串和message同时传递的Transferable对象,这些对象的所有权将被转移给消息的接收方,而发送一方将不再保有所有权。

其他窗口可以监听message事件

window.addEventListener("message", receiveMessage, false);

function receiveMessage(event)
{
  // For Chrome, the origin property is in the event.originalEvent
  // object. 
  // 这里不准确，chrome没有这个属性
  // var origin = event.origin || event.originalEvent.origin; 
  var origin = event.origin
  if (origin !== "http://example.org:8080")
    return;

  // ...
}

postMessage的具体使用示例

例如：A页面(URL是http://www.examplea.com:8080/a.html)要给B页面(URL是http://www.exampleb.com:8888/b.html)发送消息

// A页面的域名是http://www.examplea.com:8080，在A页面的script标签下加入以下代码
const winpopup = window.open('http://www.exampleb.com:8888/b.html');
// 将第二个参数targetOrigin设置为要打开的B的域名，如果设置的和要打开的页面域名不一致，会导致消息发送不出去。
winpopup.postMessage('Hello B, I am A', 'http://www.examplea.com:8080');
function receiveMessage(event) {
    const origin = event.origin;
    // 判断信息来源是否为B
    if(origin !== "http://www.examplea.com:8080") {
        return;
    }
    // data: 从其他 window 中传递过来的对象。
    // do something
    consoel.log(event.data);
}
window.addEventListener('message', receiveMessage, false);

// B页面的域名是http://www.exampleb.com:8888，在B页面的script标签中加入以下代码

//当A页面postMessage被调用后，这个function被addEventListener调用
function receiveMessage(event)
{
  // event.origin是调用 postMessage  时消息发送方窗口的 origin, 即A页面
  // 判断信息来源是否为A
  if (event.origin !== "http://www.examplea.com:8080") {
    return;
  }
  // event.source 就当前弹出页的来源页面
  // event.data 是 "Hello B, I am A"
  // 假设你已经验证了所收到信息的origin， 可以把event.source 作为回信的对象，并且把event.origin作为targetOrigin
  event.source.postMessage("hi A! the secret response is: rheeeeet!", event.origin);
}

window.addEventListener("message", receiveMessage, false);

postMessage的使用注意事项

1. 如果您不希望从其他网站接收message，请不要为message事件添加任何事件侦听器。这是一个完全万无一失的方式来避免安全问题。
1. 如果您确实希望从其他网站接收message，请始终使用origin和source属性验证发件人的身份。这不能低估：无法检查origin和source属性会导致跨站点脚本攻击。
1. 当您使用postMessage将数据发送到其他窗口时，始终指定精确的目标origin，而不是*。

如有问题，欢迎指正，谢谢🙇