跨域哈希更改通信
请考虑以下两个域:domain1.com 和domain2。
我从domain1 打开一个指向domain2 的iframe。
现在,我希望这些人能够相互通信,我已经通过在两个域上应用哈希更改事件侦听器成功实现了这一点。
这样,如果domain2 使用新的哈希调用parent.location,则父窗口(domain1) 中的哈希将被触发。此外,如果我从父级将其 src 属性更改为新哈希,则哈希更改事件会在 iframe 中触发。
这太棒了!
麻烦来了:
浏览器中的后退和前进功能变得混乱。简而言之,通过创建两个哈希实例,必须单击浏览器后退按钮两次才能更改父哈希,因为它必须首先循环遍历 iframe 的哈希。
如何在不搞乱历史对象的情况下与跨域 iframe 2 路通信?
谢谢!
Please consider the following two domains: domain1.com and domain2.
From domain1 I open an iframe that points to domain2.
Now, I want these guys to communicate with each other, which I've successfully accomplished by applying hash change event listeners on both domains.
That way, the hash in the parent window (domain1) will trigger if domain2 calls parent.location with a new hash. Also, the hash change event triggers in the iframe if I from the parent changes its src attribute to a new hash.
This works great!
Here comes the trouble:
The back and forward functionality in the browser gets messed up. Simply put, by creating two hash instances, the browser back button has to be clicked twice to get the parent hash to change since it has to cycle through the iframe's hash first.
How can I communicate with a cross-domain iframe 2-way without screwing up the history object?
Thanks!
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(2)
使用 easyXDM,它是一个 javascript 库,可以为您完成所有艰苦的工作,使您能够进行跨域通信和 RPC所有浏览器,包括 IE6。
这不会对任何当前浏览器(甚至 IE6)使用 HashTransport,因此不会更改历史记录。
您不会找到更好的东西。
您可以在此 Script Junkie 文章,或直接前往 github 上的自述文件
Use easyXDM, it's a javascript library that does all the hard work for you, enabling you to do cross-domain communication and RPC in all browsers, including IE6.
This will not use the HashTransport for any of the current browsers (not even IE6), and so will not change the history.
You will not find anything better..
You can read about some of its inner workings in this Script Junkie article, or go straight to the readme at github
跨域通信的另一种技术是 (ab) 使用
window.name
。它要求 iframe 最初具有相同域的 src,之后您移动到设置 window.name 的另一个域,然后返回到原始源(返回历史记录)。这个想法是,除非显式设置,否则window.name
不会更改,这意味着您可以跨域传输window.name
数据。此技术在以下位置有更详细的描述:
- http://skysanders.net/subtext/archive/2010/10/11/leveraging-window.name-transport-for-secure-and-efficient-cross-domain-communications.aspx< br>
- http://jectbd.com/?p=611
一定要选择避免点击的实现IE 中的声音。
不幸的是,它仍然会扰乱你的历史,但它会向前迈出一步,然后向后退到它所在的历史点。不过,一个很大的好处是您不必解析和编码 URI 字符串,而是可以立即使用 JSON。
例如使用 JSON lib
Cookie 技术也是可行的,对于您所使用的这两种技术如果你想避免历史记录更改但仍然需要http请求,则需要在目标iframe中执行ajax请求。
so:
任何页面刷新(httprequest)或 url 更改都会更新历史记录(旧版或所有 IE 版本除外),因此需要更多代码。
Another technique for crossdomain communications is (ab)using
window.name
. It requires an iframe to originally have a same-domain src initially after which you move to another domain that sets the window.name and then steps back to the original source (step back in history). The idea is that thewindow.name
does not change unless it's explicitly set, this means you can transferwindow.name
data cross domain.This technique is described in more detail on:
- http://skysanders.net/subtext/archive/2010/10/11/leveraging-window.name-transport-for-secure-and-efficient-cross-domain-communications.aspx
- http://jectbd.com/?p=611
Be sure to choose the implementation that avoids clicking sounds in IE.
Unfortunatly, it still messes around with your history, but it does a step forward and then backwards to the history point it was at. A big benefit though, is that you don't have to parse and encode URI strings, but can use JSON right away.
Using JSON lib for example
The cookie technique is viable as well, for both techniques you need to perform ajax requests in the target iframe if you want to avoid history changes but still require http request.
so:
Any page refresh (httprequest) or url change will update the history (except for old or all IE versions), so more code is required alas.