Javascript 确定哪个广告向 /eyeblaster/addineyev2.html 发出请求

Determine which advertisement made a request to /eyeblaster/addineyev2.html

提问by Tal

I have a large website that is using two large online advertisement "Remnant" providers. These providers are such that they start and stop ad campaigns on a regular basis that run on our website.

我有一个使用两个大型在线广告“Remnant”提供商的大型网站。这些提供商会定期启动和停止在我们网站上运行的广告活动。

One of the ads coming from one of the providers is incorrectly making a request to:

来自其中一个提供商的其中一个广告错误地请求：

/eyeblaster/addineyev2.html

/eyeblaster/addineyev2.html

I have determined that the file being requested is used by some websites when the ads on the website are served via iframes. This file in theory would circumvent the cross domain restrictions so that the ad provider could resize the iframe using javascript within the iframe.

我已经确定，当网站上的广告通过 iframe 投放时，某些网站会使用所请求的文件。该文件理论上可以绕过跨域限制，以便广告提供商可以在 iframe 中使用 javascript 调整 iframe 的大小。

I determined this use of the file by stumbling upon this support document:

我通过偶然发现此支持文档确定了该文件的使用：

http://support.google.com/dfp_premium/bin/answer.py?hl=en&answer=1085693

http://support.google.com/dfp_premium/bin/answer.py?hl=zh-CN&answer=1085693

My problem is that our websites do not use iframes to deliver advertisements, so the requests going to the "/eyeblaster/addineyev2.html" URI results in a 404 error, and is unnecessary. Because the error is coming from a large vendor-provided CMS the error renders with our Google Analytics tracking code on it. This has the result of inflating our apparent pageviews.

我的问题是我们的网站不使用 iframe 来投放广告，因此发送到“/eyeblaster/addineyev2.html”URI 的请求会导致 404 错误，这是不必要的。由于错误来自大型供应商提供的 CMS，因此错误会显示在我们的 Google Analytics 跟踪代码上。这会夸大我们的明显综合浏览量。

The pageview inflation can be very severe, because the 404 error page also contains ads. That 404 page could also load the faulty ad, resulting in a recursive loop of ads loading the exact same "/eyeblaster/addineyev2.html" 404 page.

浏览量膨胀可能非常严重，因为 404 错误页面还包含广告。该 404 页面也可能加载有问题的广告，导致广告递归循环加载完全相同的“/eyeblaster/addineyev2.html”404 页面。

I have thus far been unable to witness an ad making a direct request to this url via Firebug or similar developer tools. Yet, the traffic to this non-existent page is gigantic so the offending ad is certainly still in the mix. The problem is that I cannot figure out which ad is broken, so I can't tell our remnant providers to remove it. Both vendors are feigning ignorance of the issue.

到目前为止，我还没有看到广告通过 Firebug 或类似的开发人员工具直接请求这个 url。然而，这个不存在的页面的流量是巨大的，因此违规广告肯定仍在混合中。问题是我无法确定哪个广告已损坏，因此我无法告诉我们的剩余供应商将其删除。两家供应商都假装不知道这个问题。

I cannot remove the Google tracking code on the 404 error page, but I can add additional JavaScript to the page.

我无法删除 404 错误页面上的 Google 跟踪代码，但我可以向页面添加其他 JavaScript。

Is there any way that I could identify the ad causing a request to "/eyeblaster/addineyev2.html" by adding some javascript to the 404 error that results when trying to request that page inside an iframe?

有什么方法可以通过向尝试在 iframe 中请求该页面时导致的 404 错误添加一些 javascript 来识别导致对“/eyeblaster/addineyev2.html”的请求的广告？

Essentially almost a "frame buster" script that instead of busting the frame, gives information on the HTML nodes nearby the iframe element? I think it's mildly possible, but I'm not seeing a clear path at the moment.

本质上几乎是一个“frame buster”脚本，它不是破坏框架，而是提供有关 iframe 元素附近 HTML 节点的信息？我认为这是有可能的，但目前我没有看到明确的路径。

Thanks!

谢谢！

采纳答案by Miguel

To avoid that unwanted tracking you should place a dummy empty file on /eyeblaster/addineyev2.html, or, if you use nginxdo something like

为避免不必要的跟踪，您应该在 上放置一个虚拟的空文件/eyeblaster/addineyev2.html，或者，如果您使用，nginx请执行以下操作

server {
  ...

  location = /eyeblaster/addineyeV2.html { echo ""; }
}

or, better

或更好

server {
  ...

  location = /eyeblaster/addineyeV2.html { return 404 "404 - page not found";}
}

If you don`t have static hosting and cannot configure a proxy server you can put a condition in your 404 page tracking via javascript

如果您没有静态主机并且无法配置代理服务器，您可以通过 javascript 在 404 页面跟踪中设置条件

if (document.URL.indexOf('/eyeblaster/addineyeV2.html') == -1) {
   doAnalyticsTracking();
}

回答by Tal

I have found my own answer, and I'll share it here for the rare event another Web Developer is trying in vain to pinpoint an ad doing this same thing to them.

我已经找到了我自己的答案，我将在这里分享它，因为另一个 Web 开发人员试图找出对他们做同样事情的广告，但徒劳无功。

The offending digital ad was coming in with an iframe that was pointed toward "/eyeblaster/addineyev2.html" I used this knowledge, and coded the following javascript to gather information about the page that contained the iframe (ie the page with the ad on it).

有问题的数字广告带有指向“/eyeblaster/addineyev2.html”的 iframe 我使用了这些知识，并编写了以下 javascript 以收集有关包含 iframe 的页面（即带有广告的页面）的信息它）。

if(top != self) {
    $.post("/ad_diagnose/log.php", {
        a: $('#ad-div-one', top.document).html(),
        b: $('#ad-div-two', top.document).html(),
        c: $('#ad-div-three', top.document).html(),
        d: $('#ad-div-four', top.document).html(),
        e: $('#ad-div-five', top.document).html(),
    });
}

This JavaScript uses JQuery (which our CMS provider includes on every page anyway). It checks to see if the error page exists in an iframe (top != self), and then it grabs the raw html for every html element on the parent page that should contain an ad.

这个 JavaScript 使用 JQuery（我们的 CMS 提供程序在每个页面上都包含它）。它会检查错误页面是否存在于 iframe (top != self) 中，然后它会为父页面上应该包含广告的每个 html 元素抓取原始 html。

That data is wrapped into an object, and posted to a simple php script that would write a log of every value posted to it to a file.

该数据被包装到一个对象中，并发布到一个简单的 php 脚本中，该脚本会将发布到它的每个值的日志写入文件。

In the end, I received a log file with a high likelihood that the offending ad code was within. I was able to do a quick grep on the file and discovered the ad with an iframe pointing toward "/eyeblaster/addineyev2.html"

最后，我收到了一个日志文件，很有可能是违规广告代码在其中。我能够对文件进行快速 grep 并发现带有指向“/eyeblaster/addineyev2.html”的 iframe 的广告

I hope this helps someone else out there!

我希望这可以帮助其他人！

回答by Thomas

It looks like there are more publishers having this issue. I do too. Following Tals instructions I was able to log information when pointing an iframe to a 404-page on purpose, but wasn't able to catch this problem as it appears randomly and I can't check why the script is not catching it.

似乎有更多发布商遇到此问题。我也做。按照 Tals 说明，当我故意将 iframe 指向 404 页时，我能够记录信息，但无法捕获此问题，因为它是随机出现的，我无法检查脚本为什么没有捕获它。

How about adding /eyeblaster/addineyev2.html and log from this file?

添加 /eyeblaster/addineyev2.html 并从此文件登录怎么样？

I was able to determine the owner of the script doing a simple web search. It is coming from http://www.mediamind.com/But disabling "mediamind" in Google AdSense doesn't do the trick, so I asked their support to send me the file.

我能够通过简单的网络搜索来确定脚本的所有者。它来自http://www.mediamind.com/但在 Google AdSense 中禁用“mediamind”并不能解决问题，所以我请求他们的支持将文件发送给我。

I am going to test the script and if 404-calls are getting lower. Maybe I will also use the script to check for the content being loaded and determine the exect ad url to shut it down.

我将测试脚本，如果 404 呼叫越来越少。也许我还会使用脚本来检查正在加载的内容并确定要关闭它的 exec 广告 url。

回答by Brian

Just thought I would share that this is happening over at our Ozzu website as well. I was first aware of the issue when some of our members were complaining, but I didn't look too deeply as I first thought it was an isolated instance.

只是想我会分享这发生在我们的 Ozzu 网站以及。当我们的一些成员抱怨时，我第一次意识到这个问题，但我没有看得太深，因为我最初认为这是一个孤立的例子。

Over the past month I have also noticed that my error log files on the server have been higher than normal pushing the /usr partition to around 82% of its usage. I didn't put two and two together until today as I finally started looking through the errors and it appears that this is not an isolated instance with this eyeblaster type ads. There are many thousands of users coming to our site and then getting redirected to a 404 page on our website because of this. Here is a sample of one of the errors in our log file, and it appears that numerous networks are using this eyeblaster software from Media Mind:

在过去的一个月里，我还注意到服务器上的错误日志文件高于正常情况，将 /usr 分区的使用率推高至其使用率的 82% 左右。直到今天，我才将两个和两个放在一起，因为我终于开始查看错误，这似乎不是这种 Eyeblaster 类型广告的孤立实例。有成千上万的用户访问我们的网站，然后因此被重定向到我们网站上的 404 页面。以下是我们日志文件中一个错误的示例，似乎许多网络都在使用 Media Mind 的这个 eyeblaster 软件：

[Thu Dec 13 16:36:51 2012] [error] [client 123.123.123.123] File does not exist: /public_html/eyeblaster, referer: http://lax1.ib.adnxs.com/if?enc=AAAAAAAAAAAAAAAAAAAAAAAAAGC4Hvs_AAAAAAAAAAAAAAAAAAAAAMqchzp-qp9L_vlliXOoLV2gdMpQAAAAAEMUDABGAQAAQAEAAAIAAADXo0AA-FcCAAAAAQBVU0QAVVNEAKAAWAIAeAAAYk4AAgMCAQUAAIIA5BXJnQAAAAA.&cnd=%21QxtEWwidpzIQ18eCAhgAIPivCTAEOIDwBUABSMACUMOoMFgAYL4FaABwKngAgAH6AYgBAJABAZgBAaABAqgBALABALkBAAAAAAAAAADBAQAAAAAAAAAAyQEgEFk1j_LCP9kBAAAAAAAA8D_gAQA.&udj=uf%28%27a%27%2C+15986%2C+1355445408%29%3Buf%28%27c%27%2C+824221%2C+1355445408%29%3Buf%28%27r%27%2C+4236247%2C+1355445408%29%3B&ccd=%21mgWjMAidpzIQ18eCAhj4rwkgAQ..&vpid=18&referrer=http%3A%2F%2Fwww.ozzu.com%2F&dlo=1
[Thu Dec 13 16:36:56 2012] [error] [client 123.123.123.123] File does not exist: /public_html/eyeblaster

I have just contacted the Media Mind company as well to see if they have any further input. The errors in our logs are at least coming from a few ad servers such as:

我也刚刚联系了 Media Mind 公司，看看他们是否有任何进一步的意见。我们日志中的错误至少来自一些广告服务器，例如：

lax1.ib.adnxs.com
showads.pubmatic.com
ad.yieldmanager.com

So it is my impression that numerous Media companies are using this Eye Blaster software. I looked more into what Eye Blaster supposedly does, and it is some sort of technology that syncs numerous ads on the page as if they are one big ad. For instance an animation will start in one ad and end in another. Anyway it must be popular as numerous ad companies seem to be using it and as such I would probably have to disabled alot of advertisers.

所以我的印象是很多媒体公司都在使用这款 Eye Blaster 软件。我更多地研究了 Eye Blaster 应该做什么，它是某种技术，可以同步页面上的大量广告，就好像它们是一个大广告一样。例如，动画将从一个广告开始并在另一个广告中结束。无论如何它一定很受欢迎，因为许多广告公司似乎都在使用它，因此我可能不得不禁用很多广告商。

I think the best way to fix the problem would be to have Media Mind address it, but I am not sure.

我认为解决问题的最佳方法是让 Media Mind 解决它，但我不确定。

Anyway just wanted to share my experience and that this problem seems to be affecting numerous websites.

无论如何只是想分享我的经验，这个问题似乎影响了许多网站。