iframe跨域通信的通用解决方案

简介:

2个信使的情况

一、背景

在这个Web页面越来越丰富的时代,页面通过iframe嵌入其他的页面也越来越常见。但由于浏览器同源策略的限制,不同域之间属性和操作是无法直接交互的,所以在这个时候,开发者多多少少需要一些方案来突破这些限制。跨域问题涉及的地方也很多,如文档之间的消息通信、ajax请求、Cookie等,本文讨论的是iframe和父页面的消息通信。

 

二、现状

目前网上也可以找到各种解决方案(少说都有10+个,有兴趣的话可以去看看),对于现代浏览器来说,原生的postMessage API一定是不二的选择,所以各种方案的不同点均在于IE 6、7中的处理(不用兼容IE6、7的同志可以去看其他文章了)。当然这么多方案有各种优缺点,甚至有些只支持单向跨域,个人觉得实际意义不大。另外一些方案需要proxy.html这样的代理页面做中转,但是涉及服务器上的部署,并且对于多方合作来说还是有些麻烦。

三、思路

虽然不再复述现有的各种方案,但还是想交待一点上下文。相信网上看到最多方案就是利用location.hash或是window.name进行iframe的跨域通信:

  • location.hash会直接暴露在URL里,并且在一些浏览器里会产生历史记录,数据安全性不高也影响用户体验,所以不做考虑。另外由于URL大小的限制,支持传递的数据量也不大。
  • window.name相比来讲就好很多了,支持2M的数据量,并且当iframe的页面跳到其他地址时,其window.name值保持不变,副作用可以说是最小的。

讲到这思路也比较清晰了,咱们就用window.name呗,但问题又来了:只有两个页面同域时才能访问window.name。这个问题还好,只要把iframe改为与父页面同域就可以了。这又衍生了新的问题:这不是意味着只能单向通信了吗,iframe怎么向父页面发消息(不可能去改父页面的location吧)?在暗骂坑爹的同时偶然发现了一个很神奇的方法,就是想访问一个iframe的window.name时,只要将其location改为‘about:blank’即可,屡试不爽~没错这个“特性”可以视为IE6/7的一项安全性问题,但利用这个特性来进行跨域通信并没有实际的安全风险。

具体的实现见下图,在iframe的内部再创建一个iframe(我们称之为信使),父子页面轮询信使的window.name,父子页面各自使用变量保存window.name,轮询时发现有变化即被视为收到消息。基本原理就是这么简单,我们继续..

1个信使的情况

图1

作为一个通用的解决方案,我们的目标是提供一个js文件,封装通信的接口,需要通信的页面只要加载js文件就行。但在封装前,需要考虑更复杂一点的情况:当父子页面双方频率较高地双向通信时,如何进行支持?按照上述的方案,信使的window.name并没有读写锁的概念,这意味着消息很容易乱掉或被漏掉。所以更好的方案应该是:创建两个信使,分别负责”父–>子”和”子–>父”的消息传递,并且为了防止消息被冲掉,发送消息时会维护一个消息队列,在取消息时处理消息队列里的所有消息。见图2。

2个信使的情况

图2

四、封装

最后的封装就是加入了postMessage API的检测,另外也要判断是否为跨域,这样就满足了所有iframe通信的情况了。这里实现的信使只负责消息的监听和发送,所以在使用上是非常简单的:

// 父页面中
// 初始化信使, 告知与其交互的iframe引用
var messenger = Messenger.initInParent(iframeEl);
 
// 监听消息
messenger.onmessage = function (data) {
          ...
};
 
// 发送消息
messenger.send(message);
// iframe中
// 初始化信使
var messenger = Messenger.initInIframe();
 
// 监听消息
messenger.onmessage = function (data) {
      ...
};
 
// 发送消息
messenger.send(message);

具体使用可以参考下方的demo : )

五、总结

虽然国内也有人提过使用”about:blank”进行iframe通信的,但是代码的封装和可读性都不是太好,本方案是一日本人所提出,我觉得处理的很好,所以就拿出来和大家分享下。虽然尝试过优化轮询那一块,但暂时无果,有兴趣的朋友可以一起研究下~

DEMO:点击这里

脚本下载:http://biqing.alloyteam.com/lab/messenger/messenger.js

GitHub:https://github.com/biqing/MessengerJS





本文转自Barret Lee博客园博客,原文链接:http://www.cnblogs.com/hustskyking/archive/2013/03/29/lightweight-solution-for-an-iframe-cross-domain-communication.html,如需转载请自行联系原作者

目录
相关文章
|
Kubernetes 容器 Perl
【kubernetes】解决:pvc 一直处于Terminating 无法删除的问题
【kubernetes】解决:pvc 一直处于Terminating 无法删除的问题
1811 0
uniapp发送formdata表单请求(全网最简单方法)
因为uniapp不支持直接传输formdata,只提供了uploadFile方法上传文件,但是利用该方法就可以传输formdata了。
3779 1
Echarts组件legend属性显示数据和icon图片自定义的解决方案
Echarts组件legend属性显示数据和icon图片自定义的解决方案
1217 0
|
9月前
|
弹性计算 运维 负载均衡
阿里云轻量应用服务器产品介绍、收费标准以及搭建个人博客教程参考
本文为大家介绍阿里云轻量应用服务器的产品优势、应用场景、使用须知、地域与网络连通性、与云服务器ECS的区别以及使用轻量应用服务器搭建WordPress个人博客的图文教程,以供大家了解和使用轻量应用服务器。
|
监控 大数据 Java
使用Apache Flink进行大数据实时流处理
Apache Flink是开源流处理框架,擅长低延迟、高吞吐量实时数据流处理。本文深入解析Flink的核心概念、架构(包括客户端、作业管理器、任务管理器和数据源/接收器)和事件时间、窗口、状态管理等特性。通过实战代码展示Flink在词频统计中的应用,讨论其实战挑战与优化。Flink作为大数据处理的关键组件,将持续影响实时处理领域。
2693 5
|
人工智能 自然语言处理 Linux
NobodyWho:每个NPC都有独立灵魂!Godot插件实现本地LLM对话,离线生成多线剧情
NobodyWho 是一款为 Godot 游戏引擎设计的插件,支持在本地运行 LLM,实现互动小说创作,无需联网,确保隐私和高性能。
1175 14
NobodyWho:每个NPC都有独立灵魂!Godot插件实现本地LLM对话,离线生成多线剧情
|
Shell 开发工具 git
git怎么处理文件夹名称大小写重命名问题
git怎么处理文件夹名称大小写重命名问题
834 0
|
数据可视化
漏刻有时数据可视化Echarts组件开发(16):map3D实现360连续旋转的解决方案
漏刻有时数据可视化Echarts组件开发(16):map3D实现360连续旋转的解决方案
305 0
|
Web App开发 JSON JavaScript
vue学习:chrome 中 vuetools 开发插件 的下载、安装
这篇文章介绍了如何在Chrome浏览器中下载、安装并测试Vue.js开发插件——vue-devtools。
4505 0
vue学习:chrome 中 vuetools 开发插件 的下载、安装
|
前端开发
ElementPlus中total出现el.pagination.total,显示总数没有出现怎样解决,出现的是英文,不是中文如何解决,这里如何配置中文,配置中文
ElementPlus中total出现el.pagination.total,显示总数没有出现怎样解决,出现的是英文,不是中文如何解决,这里如何配置中文,配置中文

热门文章

最新文章