说说跨域那些事儿

Author Avatar
墨冥 12月 31, 2016
  • 在其它设备中阅读本文章

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

兼容性查找

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

什么是跨域

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

  • 协议不同,如http, https;
  • 端口不同;
  • 主域相同,子域不同;
  • 主域不同;
  • ip地址和域名之间也算是跨域,浏览器不会自动做ip域名的映射;

解决方案

  • document.domain
  • window.name
  • jsonp
  • postMessage
  • cors

document.domain

  • 关键点
    • 跨域分为两种,一种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;
  • 兼容性:所有浏览器都支持;
  • 优点:
    • 最简单的利用了浏览器的特性来做到不同域之间的数据传递;
    • 不需要前端和后端的特殊配制;
  • 缺点:
    • 大小限制:window.name最大size是2M左右,不同浏览器中会有不同约定;
    • 安全性:当前页面所有window都可以修改,很不安全;
    • 数据类型:传递数据只能限于字符串,如果是对象或者其他会自动被转化为字符串,如下;
      window.name非字符串测试
  • 使用方式:修改window.name的值即可;

jsonp

  • 关键点:浏览器对XHR做了同源策略,但并没有将这种方式延续到script上(其实还有iframe,img等),从而可以利用动态script标签技术来做到跨域请求的作用。至于为什么会这样设计,本人也不太清楚,有可能是历史遗迹(漏洞),有可能是某些方面的技术瓶颈,也有可能是为了满足某些需求专门定制的,总之这项技术方案我们过去可以用,现在可以用就ok,至于将来应该也是会存在的,毕竟现在已经应用在很多家站点上,就算会废弃,也会有一段时间迭代。
  • 兼容性:所有浏览器都兼容这种方式;
  • 优点:很明显前端可以很轻松的做到跨域请求;
  • 缺点
    • 只能通过GET方式请求,一方面是参数长度有限制,二是安全性比较差;
    • 后端需要知道前端的cb是什么样的结构,主要在参数和回调名;
    • 后端需要进行参数和cb的拼接然后才能执行;
  • 使用方式
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    /** 前端生成script标签,并将src中传入需要执行的callback **/
    <script type="text/javascript">
    var ele = document.createElement('script');
    ele.type = "text/javascript"
    ele.src = "http://example.com?jsonp=cb";
    document.body.appendChild(ele);
    </script>
    /** 后端接到参数后给callback加入参数并执行 **/
    <?php
    $cb = $_GET['cb'];
    $data = array('test1', 'test2', 'test3');
    echo $cb.'('.json_encode($data).')';
    ?>

postMessage

  • 关键点:postMessage是h5引入的一个新概念,现在也在进一步的推广和发展中,他进行了一系列的封装,我们可以通过window.postMessage的方式进行使用,并可以监听其发送的消息;
  • 兼容性:下图是postMessage的兼容图,移动端可以放心用,但是pc端需要做降级处理,具体可以根据文中介绍的这几种跨域方式来则情选择;
    poseMessage兼容性
  • 优点
    • 不需要后端介入就可以非常简单的的做到跨域,一个函数外加两个参数(请求url,发送数据)就可以搞定;
    • 移动端兼容性好;
  • 缺点
    • 无法做到一对一的传递方式:监听中需要做很多消息的识别,由于postMessage发出的消息对于同一个页面的不同功能相当于一个广播的过程,该页面的所有onmessage都会收到,所以需要做消息的判断;
    • 安全性问题:三方可以通过截获,注入html或者脚本的形式监听到消息,从而能够做到篡改的效果,所以在postMessage和onmessage中一定要做好这方面的限制;
    • 发送的数据会通过结构化克隆算法进行序列化,所以只有满足该算法要求的参数才能够被解析,否则会报错,如function就不能当作参数进行传递;
  • 使用方式:下面是前段时间写的一个通信的函数,sendMessage负责发送消息,bindEvent负责消息的监听并处理,可以通过代码来做一个大致了解;
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    25
    26
    27
    28
    29
    30
    31
    32
    33
    34
    35
    36
    37
    38
    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

  • 关键点:cors是一种通过前后端http header配置来进行跨域的一种方式;
  • 兼容性:如果不考虑pc端的IE,移动端的opera的话那兼容性还是不错的,针对ie和opera可以做适当的降级处理;
    poseMessage兼容性
  • 安全策略
    • 请求
      • origin:通过http头中的origin判断域名是否是允许的;
      • Example-Same-origin:如果http origin不存在,最好能够自己在请求头中加入该参数来标示是否是同源,true表示请求来自于同域名下(同域名下请求不带origin);如果该字段存在并且为true则允许请求接口,否则禁止;
      • Example_source_origin:该参数同origin,是在origin不存在的情况下用来标示请求来源的url
    • 返回
      • Access-Control-Allow-Origin: originorigin表示允许哪些网站请求,不建议设置为*;
      • Access-Control-Expose-Headers:Example-Access-Control-Allow-Source-Origin,允许http返回中包含该字段,可以通过这种方式在返回头中加入自定义字段,如该例子中的Example-Access-Control-Allow-Source-Origin;
  • 优点
    • 前端方便不少,只需要发请求而不用考虑跨域问题;
    • 安全性能够得以控制和保障;
  • 缺点
    • 兼容性不全面,需要做降级处理;
  • 使用方式
    • 正常请求即可,无论是你要用xhr,还是用一些封装好的组件,如fetchfetchJsonp,亦或是jquery一类的技术均可;
    • 后端在response时需要设置一定的配置参数,并保证安全策略,具体方案可以参照下面安全策略模块;