[经验] 跨域方案

本文源自一次内部关于跨域的讨论分享的总结

理解跨域的重点在于：了解跨域产生的场景、原理

跨域问题只在浏览器客户端环境下出现，是因为浏览器出于安全考虑设置的同源策略引发，因此解决跨域问题通常采用的思路有两种：
a. 绕过浏览器的同源策略约束
b. 遵循新的跨域规范

浏览器同源策略

同源策略：不一样域的客户端在没明确受权的状况下，不能读写对方的资源
同域：协议、域名、端口号均相同
好比：

http://abc.com  vs  https://abc.com
http://ab.abc.com  vs  http://a.abc.com 
127.0.0.1:3000  vs  127.0.0.1:4000

哪些行为会受到浏览器同源策略的约束呢？

• ajax请求 XMLHttpRequest
  注意：浏览器并不会限制跨域请求的发出，即服务端再未作其余限制的状况下仍可收到跨域请求，浏览器只是限制了ajax请求返回信息的读取、cookie写入等操做
  扩展：服务端如何限制仅接收指定域名请求? refer?
• fetch
• 非同域窗体之间（好比iframe引入的状况的父子窗体）不能直接进行数据通信或共享
• Web 字体 (CSS 中经过 @font-face 使用跨域字体资源)
• WebGL 贴图
• 使用 drawImage 将 Images/video 画面绘制到 canvas

等等

哪些标签能够加载非同源资源？
script img link iframe
跨域方案的思路a也就是基于以上几种标签

JSONP -- 思路满分

json with padding

基本原理：利用script标签的src属性容许加载非同源资源，加载后js解析器将执行资源代码，目标服务器在数据外层包裹一个客户端已经定义好的函数并返回

服务端接口返回一段可执行js脚本
"hello browser"   =>   callback("hello browser")

先后端交互流程：

• 首先在浏览器端注册一个全局函数callback。
• 浏览器端建立一个script标签，将src指向目标服务端资源地址，并带上callback参数，告诉服务端回调函数名称，将此script标签插入到Dom中。
• 服务器生成返回json数据 ，获取请求中的callback函数名参数，再将json数据以参数填充的方式，和函数名参数拼接：callback+’(‘+json+’)’，最后将拼接完成的数据返回。
• 浏览器端，解析script标签，并执行返回的javascript 文档，此时数据做为参数，传入到了客户端预先定义好的callback 函数里（动态执行回调函数）。

优缺点对比

优：

• 兼容性极佳，在不支持XMLHttpRequest的浏览器中也能够用于模拟异步请求

缺：

• 只容许get请求: jsonp跨域原理是经过script标签加载跨域资源，不可能支持post请求
• 存在必定安全隐患: 本质上来讲，jsonp是一种脚本注入(Script Injection)行为
• 须要服务端配合支持：若是一个接口同时须要适配jsonp和正常请求，须要特殊处理没有错误处理支持
• 若是动态脚本插入有效，就执行调用；若是无效，就静默失败：不能从服务器捕捉到 404 错误，也不能取消或从新开始请求。（自行设置定时器，超时后没有进入回调即断定为请求失败 ）

栗子 ——淘宝和天猫经过jsonp跨域共享cookie

在淘宝(www.taobao.com)登陆后，切换到天猫(www.tmall.com)，会看到顶栏已经有登陆用户信息。打开控制台，刷新tmall页面，能够看到以下jsonp请求，其中第一个即为获取到登陆信息的关键请求：

打开该请求的Response内容：

这段返回内容(本质上是js代码)到达客户端后，将会被解析执行

利用消息通讯机制实现的跨域请求

@Update ：不论是post message、window.name共享、location.hash共享，这类方案的原理都是依赖消息通讯机制实现的，故更改标题

以我的常常用到的Frame代理为例

基本原理：在目标服务器放置一个代理文件(proxy_frame.html)，经过加载该代理文件和服务端进行数据交互（同域请求），返回数据经过消息通信(如post message)返回给上层应用以实现跨域数据交互
a.b.com域页面

其实是利用窗体之间通信方式 将跨域请求转化为同域请求

先后端交互流程：（以nej框架的实现为例）

• 假设a.b.com的应用须要向x.y.com的服务器取数据，首先在x.y.com域服务器上预先放置代理文件，并以iframe载入该代理文件
• 服务器端返回带配置的代理文件
• 代理文件载入完成后，a.b.com域的应用将要发送的请求指令经过消息通讯方式传递给代理文件
• 代理文件验证a.b.com是否在预先配置的白名单中，若是不在则异常返回，不然直接发送请求至x.y.com域服务器
• 服务器返回数据至代理文件
• 代理文件经过消息通信机制将请求结果返回给a.b.com域的应用

窗体间消息通讯方式：

针对高版本浏览器：HTML5 Web Message
针对Trident引擎低版本浏览器（ie6-7）：window.name代理（复杂结构须要stringify，启用队列修改）

优缺点对比：

优：

• 服务端无需额外支持：仅须要放置代理用的html文件便可
• 对请求method完整支持：get、post、put等等
• 兼容性较好：须要一些兼容处理（主要针对消息通讯方式）

缺：

• 首次请求存在延时：因为首次发起请求时须要载入代理文件，在载入代理文件以前的全部请求都会存在必定的延时
• 低版本浏览器并发请求延时较大：因为低版本浏览器受限于消息通信机制，对于并发量大的请求返回时可能存在较大延时

Cross-Origin Resource Sharing规范 -- 简称CORS

为了解决跨域问题出现的标准规范
经过增长一系列请求头和响应头，规范安全地进行跨站数据传输，它要求浏览器必须能支持CORS规范定义的请求头和策略执行，而且服务端须要解析这些新的请求头并按照策略返回对应的响应头和请求的资源

分为如下三种请求场景：

附录：对 CORS 安全的首部字段集合

相关请求头和响应头（主要）

响应头：

请求头：

如何使用？

直接使用ajax(根据浏览器版本选择XHR或XDR对象)或fetch便可，客户端只需按规范设置请求头
服务端按规范识别并返回对应响应头，还能够对请求域名进行过滤处理
好比使用Nginx配置：（待补充）

仍是看几个栗子：

客户端发起一个get请求，观察一次成功简单请求的请求头与响应头：

客户端发起一个post请求，并设置Content-Type为application/xml，观察一次成功预检+正式请求的请求头与响应头：

客户端发起一个post请求，并设置设置特殊标志位 withCredentials为true ，观察一次成功预检+正式请求的请求头与响应头：

优缺点：

优：

• 标准 规范 安全
• 对请求method完整支持：get、post、put等等
• 完整的错误处理：使用XMLHttpRequest对象或FetchAPI发送请求

缺：

• 兼容程度较低：须要高版本浏览器支持，Trident引擎的浏览器须要IE10以上才完整支持

IE6-7 彻底不支持CORS
IE8-9 仅支持不带凭证的CORS跨域请求

其余

WebSocket

创建socket长链接，须要验证，本质上能够视为安全，不存在跨域限制
因为资源消耗较大，除了一些特殊场景，通常不使用

服务端反向代理

将本域服务端配置成 须要跨域获取的资源的 反向代理服务器
好比：使用Nginx配置请求转发：proxy_pass

FLASH代理

与frame代理模式相似，请求经过Flash来发送(proxy_flash.swf放置在同源站)，利用Flash的策略文件crossdomain.xml来控制资源的共享权限，获取目标服务器请求返回数据
---至关于把iframe改为flash

还有例如 img ping 等等等等

总结

跨域永远是无奈之举，常规状况下不该该出现

针对少许须要跨域Get请求的场景 ： JSONP还是不错的选择
针对整站大量跨域请求 ：
—— 兼容性要求高： iFrame代理跨域/服务端反向代理

—— IE10以上兼容支持： CORS规范

检测浏览器支持： 高版本使用CORS规范，低版本自动降级使用iFrame代理