「友好iFrame」檢測：如何在首頁中查找嵌套的iframe？

我在「友好的iframe」環境中遇到了具有挑戰性的iFrame檢測問題。我需要從window.top中識別出window.top.document中的哪個外部域iframe元素加載到本身內部，而另一個iframe具有與window.top相同的域，協議和端口。「友好iFrame」檢測：如何在首頁中查找嵌套的iframe？

所以，這裏的中心問題：在頁面A上，如何確定JavaScript中的iFrame B包含iFrame C？此外，Page A和iFrame C具有相同的域，協議和端口，並且可以相互通信。 iFrame B在不同的域上。我想找到一個與iFrame的C對頁A.相關

曾出現過

可能的事情，沒有工作的一個DOMElement：

document.referrer匹配。頁面A將頁面A上的所有iframe的src屬性與iFrame C中的document.referrer屬性相匹配。不幸的是，如果頁面A上的多個iframe使用iframe B上的相同src加載內容，則這不起作用。它也不起作用if iframe B的src屬性是about:blank或javascript:something。
window.location.hash通過查看iframe的src屬性進行通信。頁面A無法獲得iFrame B的window.location.hash，因此沒有運氣。
這已經在IE 6和7中工作，所以有沒有 window.postMessage支持。抱歉。

附加信息：

這是一種被稱爲「易用的iframe」構造。友好的iFrames（FIF）在廣告行業中很常見。以下是它們的工作方式：

發佈商網站上的一個頁面，例如Page Foo.com，它從some-random-ad-server.com注入iframe B.然後在some-random-ad-server.com上的iframe B中，另一個iframe C從foo.com加載。所以：

我有機會（即DOM操作）網頁A與iframe C.頁A可以訪問的iFrame C.
沒有瀏覽的網頁或iframe C具有訪問的iFrame B.

來源

2012-10-24 smithclay

我意識到這是舊的，但我很好奇客戶端解決方案，並跑過這篇文章。我使用服務器端來處理這個，爲什麼不使用服務器端作爲最後的手段？授予引用者在服務器端是粗略的，但是當處理iframed頁面時，引用者非常可靠，可以與本地應用程序和引用應用程序的主機進行比較。

這裏是我如何做ASP.NET/C#它（同樣的事情可以用PHP來完成，等）

// set referrer 
if (Request.UrlReferrer != null && Request.Url.Host != Request.UrlReferrer.Host) 
{ 
    Session["Referrer"] = Request.UrlReferrer.OriginalString; 
}

來源

2013-05-23 23:35:00 Skowronek

「友好iFrame」檢測：如何在首頁中查找嵌套的iframe？

回答

相關問題