说说跨域那些事儿

摘要：首先纠正一个误区，跨域并非浏览器限制了发起跨站请求的这种能力，恰恰相反，我们可以发出请求，服务端也可以接收到请求并正常返回数据，只不过在返回之后浏览器会阻止非同源数据，从而在控制台打出一系列报错信息。

首先纠正一个误区，跨域并非浏览器限制了发起跨站请求的这种能力，恰恰相反，我们可以发出请求，服务端也可以接收到请求并正常返回数据，只不过在返回之后浏览器会阻止非同源数据（response），从而在控制台打出一系列报错信息。
原文地址：说说跨域那些事儿，迁移到简书上来和大家共享

文章中会涉及一系列兼容性的图解（mdn & can i use）和一些专有名词（mdn），可以通过两个渠道来查看

Can I Use

MDN

定义就不说了，从字面也可以看其含义，首先我们认识下哪些情况属于跨域，可以分为以下几点：

协议不同，如http, https；

端口不同；

主域相同，子域不同；

主域不同；

ip地址和域名之间也算是跨域，浏览器不会自动做ip域名的映射；

document.domain

window.name

jsonp

postMessage

cors

关键点

跨域分为两种，一种xhr不能访问不同源的文档，另一种是不同window之间不能进行交互操作;

document.domain主要是解决第二种情况，且只能适用于主域相同子域不同的情况；

document.domain的设置是有限制的，我们只能把document.domain设置成自身或更高一级的父域，且主域必须相同。例如：a.b.example.com中某个文档的document.domain可以设成a.b.example.com、b.example.com 、example.com中的任意一个，但是不可以设成c.a.b.example.com，因为这是当前域的子域，也不可以设成baidu.com，因为主域已经不相同了。

兼容性：所有浏览器都支持；

优点：

可以实现不同window之间的相互访问和操作；

缺点：

只适用于父子window之间的通信，不能用于xhr；

只能在主域相同且子域不同的情况下使用；

使用方式

a（当前页面或父页面）页面中加入document.domain = "example.com";

b（当前页面或子页面）页面中加入document.domain = "example.com";

a页面访问b页面里面的数据或者方法；

关键点：window.name在页面的生命周期里共享一个window.name;

兼容性：所有浏览器都支持；

优点：

最简单的利用了浏览器的特性来做到不同域之间的数据传递；

不需要前端和后端的特殊配制；

缺点：

大小限制：window.name最大size是2M左右，不同浏览器中会有不同约定；

安全性：当前页面所有window都可以修改，很不安全；

数据类型：传递数据只能限于字符串，如果是对象或者其他会自动被转化为字符串，如下；

使用方式：修改window.name的值即可；

关键点：浏览器对XHR做了同源策略，但并没有将这种方式延续到script上（其实还有iframe，img等），从而可以利用动态script标签技术来做到跨域请求的作用。至于为什么会这样设计，本人也不太清楚，有可能是历史遗迹（漏洞），有可能是某些方面的技术瓶颈，也有可能是为了满足某些需求专门定制的，总之这项技术方案我们过去可以用，现在可以用就ok，至于将来应该也是会存在的，毕竟现在已经应用在很多家站点上，就算会废弃，也会有一段时间迭代。

兼容性：所有浏览器都兼容这种方式；

优点：很明显前端可以很轻松的做到跨域请求；

缺点

只能通过GET方式请求，一方面是参数长度有限制，二是安全性比较差；

后端需要知道前端的cb是什么样的结构，主要在参数和回调名；

后端需要进行参数和cb的拼接然后才能执行；

使用方式

/** 前端生成script标签，并将src中传入需要执行的callback **/



/** 后端接到参数后给callback加入参数并执行 **/

关键点：postMessage是h5引入的一个新概念，现在也在进一步的推广和发展中，他进行了一系列的封装，我们可以通过window.postMessage的方式进行使用，并可以监听其发送的消息；

兼容性：下图是postMessage的兼容图，移动端可以放心用，但是pc端需要做降级处理，具体可以根据文中介绍的这几种跨域方式来则情选择；

优点

不需要后端介入就可以非常简单的的做到跨域，一个函数外加两个参数（请求url，发送数据）就可以搞定；

移动端兼容性好；

缺点

无法做到一对一的传递方式：监听中需要做很多消息的识别，由于postMessage发出的消息对于同一个页面的不同功能相当于一个广播的过程，该页面的所有onmessage都会收到，所以需要做消息的判断；

安全性问题：三方可以通过截获，注入html或者脚本的形式监听到消息，从而能够做到篡改的效果，所以在postMessage和onmessage中一定要做好这方面的限制；

发送的数据会通过结构化克隆算法进行序列化，所以只有满足该算法要求的参数才能够被解析，否则会报错，如function就不能当作参数进行传递；

使用方式：下面是前段时间写的一个通信的函数，sendMessage_负责发送消息，bindEvent_负责消息的监听并处理，可以通过代码来做一个大致了解；

Storage.prototype.sendMessage_ = function(type, params, fn) {
    if (this.topWindow) {
        this.handleCookie_(type, params, fn);
        return;
    }
    var eventId = this.addToQueue_(fn, type);
    var storageIframe = document.getElementById("mip-storage-iframe");
    var element = document.createElement("a");
    element.href = this.origin;
    var origin = element.href.slice(0, element.href.indexOf(element.pathname) + 1);        

    storageIframe.contentWindow.postMessage({
        type: type,
        params: params,
        eventId: eventId
    }, origin);
}

Storage.prototype.bindEvent_ = function() {
    window.onmessage = function (res) {
        // 判断消息来源            
        if (window == res.source.window.parent &&
            res.data.type === this.messageType.RES &&
            window.location.href.match(res.origin.host).length > 0) {                
            var fn = this.eventQueue[res.data.eventId];
            fn && fn();
            delete this.eventQueue[res.data.eventId];
            // reset id
            var isEmpty = true;
            for (var t in this.eventQueue) {
                isEmpty = false;
            }
            if (isEmpty) {                    
                this.id = 0;
            }
        }                    
    }.bind(this);
}

关键点：cors是一种通过前后端http header配置来进行跨域的一种方式；

兼容性：如果不考虑pc端的IE，移动端的opera的话那兼容性还是不错的，针对ie和opera可以做适当的降级处理；

安全策略

请求

origin：通过http头中的origin判断域名是否是允许的；

Example-Same-origin：如果http origin不存在，最好能够自己在请求头中加入该参数来标示是否是同源，true表示请求来自于同域名下（同域名下请求不带origin）；如果该字段存在并且为true则允许请求接口，否则禁止；

Example_source_origin：该参数同origin，是在origin不存在的情况下用来标示请求来源的url；

返回

Access-Control-Allow-Origin: origin，origin表示允许哪些网站请求，不建议设置为*；

Access-Control-Expose-Headers:Example-Access-Control-Allow-Source-Origin，允许http返回中包含该字段，可以通过这种方式在返回头中加入自定义字段，如该例子中的Example-Access-Control-Allow-Source-Origin;

优点

前端方便不少，只需要发请求而不用考虑跨域问题；

安全性能够得以控制和保障；

缺点

兼容性不全面，需要做降级处理；

使用方式

正常请求即可，无论是你要用xhr，还是用一些封装好的组件，如fetch，fetchJsonp，亦或是jquery一类的技术均可；

后端在response时需要设置一定的配置参数，并保证安全策略，具体方案可以参照下面安全策略模块；