3

我在“友好的 iframe”环境中遇到了一个具有挑战性的 iFrame 检测问题。我需要确定从window.top哪个外部域 iframe 元素window.top.document加载到自身内部，另一个 iframe 具有相同的域、协议和端口作为window.top.

所以这里的核心问题是：在页面 A 上，如何在 JavaScript 中确定 iFrame B 包含 iFrame C？同样，Page A 和 iFrame C 属于相同的域、协议和端口，并且可以相互通信。iFrame B 位于不同的域中。我想在页面 A 上找到与 iFrame C 关联的 DOMElement。

可能已经尝试但没有奏效的事情：

  • document.referrer匹配。页面 A 将页面 Asrc上所有 iframe 的document.referrer属性与 iFrame C 中的属性相匹配。不幸的是，如果页面 A 上的多个 iframe 在 iframe B 上加载具有相同 src 的内容，这将不起作用。如果该src属性也不起作用iframe B 是about:blank或javascript:something。
  • window.location.hash通过查看srciframe 的属性进行通信。页面 A 无法获得window.location.hashiFrame B，所以那里没有运气。
  • 这必须在 IE 6 和 7 中工作，所以没有window.postMessage 支持。对不起。

附加信息：

这是一个名为“Friendly iFrames”的配置。友好的 iFrame (FIF) 在广告行业中很常见。以下是它们的工作方式：

发布商网站上的一个页面，比如页面 A foo.com，从 some-random-ad-server.com 注入 iframe B。然后在 some-random-ad-server.com 上的 iframe B 内部，从 foo.com 加载另一个 iframe C。所以：

  • 我可以从 iFrame C 访问（即 DOM 操作）页面 A。页面 A 可以访问 iFrame C。
  • 页面 A 或 iFrame C 上的任何内容都无法访问 iFrame B。
4

1 回答 1

0

我意识到这已经过时了，但我对客户端解决方案很好奇，并浏览了这篇文章。我正在使用服务器端来处理这个问题，为什么不使用服务器端作为最后的手段呢？授予的引荐来源网址在服务器端是粗略的，但是在处理 iframed 页面时，引荐来源网址非常可靠，可以与本地应用程序的主机和引荐应用程序进行比较。

这是我在 ASP.NET/C# 中完成的方式（同样的事情可以在 PHP 等中完成）

// set referrer
if (Request.UrlReferrer != null && Request.Url.Host != Request.UrlReferrer.Host)
{
    Session["Referrer"] = Request.UrlReferrer.OriginalString;
}
于 2013-05-23T23:35:00.800 回答