如何在帧之间进行通信？ [英] How to communicate between frames?
问题描述
有一个页面A带有一个显示页面B的框架。现在页面B是页面B的一部分一个完全不同的产品在一个单独的域中。
现在，他们希望当点击B中的选项时，整个页面被重定向到A中的另一个页面。是A的URL类似于 www.client.A.com/Order/Details/123 ，当我们点击时它应该重定向到像 www.client.A.com/Order/Edit/123 但是B不知道关于A的任何信息。它不知道当前选择了哪个订单＃或者关于A的任何信息。页面A谁拥有框架B知道它。
现在我的解决方案只是重定向到AllOrders，所以像client.MyCompany / Orders
但是因为B不知道哪个客户端正在调用它（它是一个多租户应用程序），所以我会添加它在webconfig中。 （所以每个客户端都有自己的具有不同值的webconfig）。
我不觉得这个解决方案是最优的，但我想不出其他的东西！我已经尝试将所需的网址在页面A中隐藏的Div（因为A确实知道所有信息），然后尝试从B读取整个页面的DOM以找到它....不幸的是，我只能访问框架B的DOM ...（我用jquery试过）。
我知道框架是邪恶的，但它是如何书写的......任何想法？
谢谢！
如果父页面A和iframe页面B是在不同的域中，您将无法通过B的父属性访问方法或字段，A中的脚本也不能访问B的内容，也不能在A和B之间共享全局变量。页面A和页面B是浏览器安全模型的关键部分。正是通过阅读银行网页的JavaScript的内部变量，防止evil.com打包在线银行网页并窃取您的帐户信息。
如果您有需要最新一代浏览器的奢侈品，你可以使用这里提到的其他答案中提到的postmessage技术。如果您需要支持旧浏览器，则可以在浏览器中使用跨域客户端脚本技术传递少量信息。其中一个例子是使用iframe在外部页面A和内部页面B之间传递信息。这并不容易，涉及很多步骤，但可以完成。我前一段时间写了文章。
您无法从父页面A监视B的iframe中的点击次数。这违反了多个级别的浏览器安全策略。 （单击劫持）您无法看到B的URL何时更改 - A可以写入iframe.src属性来更改URL，但是一旦iframe.src指向与A域不同的域，A不能再读取iframe.src属性。
如果A和B位于同一根域的不同子域中，您可能有机会降低域到一个共同的根。例如，如果外部页面A托管在子域名A.foo.bar.com中，并且B托管在子域名foo.bar.com中，则可以将页面A中的域名降低到foo.bar.com（通过分配A脚本中的window.domain =foo.bar.com）。然后，页面A将作为页面B的对等体，然后二者可以根据需要访问对方的数据，即使A在技术上来自不同于B域的域。我写了一篇关于域名降价。
域降低只能剥离最内层的子域以在根域的上下文中操作。您不能将A.foo.bar.com更改为abc.com。
将域名降至通用根域也存在一定风险。当您在自己的子域中操作页面时，您的html和脚本将从其他子域中分离出公共根域。如果某个其他子域中的服务器受到攻击，它并不会真正影响您的html页面。
如果您将网页的域名降低到公共根域，则会将您的内部公开给运行在公共根域中的脚本，并从其他子域的脚本其领域的共同根。如果某个其他子域中的服务器遭到入侵，它将有权访问您的脚本内部，因此它也可能危及您的子域。
I'm maintaining an application that goes sort of like this:
There is a Page A with a Frame that shows Page B. Now page B is part of a completely different product in a separate domain.
Now, they want that when an option in B is clicked, the WHOLE page is redirected to another page in A. The problem is that the url of A is something like www.client.A.com/Order/Details/123, and when we click in be it should redirect to something like www.client.A.com/Order/Edit/123 but B doesn't know anything about A. It doesn't know which order # is currently selected or anything about A. Page A who has the frame B does know it.
For now my solution has been to just redirect to the AllOrders so something like client.MyCompany/Orders
but since B doesn't know which client is calling it (its a multi-tenant app), I'll add it in the webconfig. (so each client has its own webconfig with a different value).
I dont find this solution optimal but I can't think of anything else! I already tried putting the needed url in page A in a hidden Div (since A does know all the info) and then trying to read the whole DOM of the page from B to find it.... unfortunately I can only get access to Frame B's DOM... (I tried with jquery).
I know frames are evil, but this is how it is written... any ideas?
Thanks!
If the parent page A and the iframe page B are in different domains, you will not be able to access methods or fields via B's parent property, nor will script in A be able to reach into B's content, nor will you be able to share global variables between A and B. This boundary placed between page A and page B is a key part of the browser security model. It's what prevents evil.com from wrapping your online bank web page and stealing your account info just by reading the internal variables of the javascript of the bank's web page.
If you have the luxury of requiring the latest generation of browsers, you can use the postmessage technique mentioned in one of the other answers here. If you need to support older browsers, you may be able to pass small amounts of information using cross-domain client scripting techniques in the browser. One example of this is to use iframes to communicate info between the outer page A and the inner page B. It's not easy and there are many steps involved, but it can be done. I wrote an article on this awhile ago.
You will not be able to monitor clicks in B's iframe from the parent page A. That's a violation of browser security policies at multiple levels. (Click hijacking, for one) You won't be able to see when B's URL changes - A can write to the iframe.src property to change the URL, but once the iframe.src points to a different domain than A's domain, A can no longer read the iframe.src property.
If A and B are in different subdomains of the same root domain, you may have an opportunity to "lower" the domain to a common root. For example, if the outer page A is hosted in subdomain A.foo.bar.com, and B is hosted in subdomain foo.bar.com, then you can lower the domain in page A to foo.bar.com (by assigning window.domain = "foo.bar.com" in A's script). Page A will then behave as a peer of page B and the two can then access each other's data as needed, even though A is technically being served from a different domain than B. I wrote an article on domain lowering, too.
Domain lowering can only peel off innermost subdomains to operate in the context of a root domain. You can't change A.foo.bar.com to abc.com.
There is also a slight risk in lowering domains to a common root domain. When you operate your page in its own subdomain, your html and script are segregated from the other subdomains off the common root domain. If a server in one of the other subdomains is compromised, it doesn't really affect your html page.
If you lower your page's domain to the common root domain, you are exposing your internals to script running on the common root domain and to script from other subdomains that has also lowered its domain to the common root. If a server in one of the other subdomains is compromised, it will have access to your script's internals and therefore it may have compromised your subdomain as well.
这篇关于如何在帧之间进行通信？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
