Chrome扩展程序：确定背景页面iframe的网页请求？ [英] Chrome extension: identify web requests of background-page iframe?

问题描述

我正在撰写一个Chrome扩展程序，以用户的名义定期检查网页。为了不引人注意，该页面被加载到扩展程序隐藏的背景页面上的iframe中。 是否可以识别由此iframe发出的网页请求？

我的初始实验（见下文）似乎表明这很棘手。获取特定选项卡的所有Web请求都很简单：您拥有tabId，并可以使用该tabId过滤Web请求（通过WebRequest API）。但是对于后台页面的iframe，目前还不清楚tabId equivalent标识符是什么，或者如何使用它来过滤web请求。

有什么想法？

我的初始实验细节如下。
frameId值看起来很有希望，但我不认为它在整个扩展中是唯一的。

这个问题已经被要求用于Firefox：识别来自隐藏的DOM窗口（或其中的一个iframes）

==实验==

作为实验，I：

• 使用WebRequest API收听所有Web请求


• 创建一个iframe
  

以下是捕获的iframe网页请求：

  {
frameId：2，
method：GET，
parentFrameId：0，
requestId：11988，
tabId：-1，
timeStamp：1395423892612.272，
type：sub_frame，
url： http://en.wikipedia.org/wiki/Frog
} 
  

tabId和parentFrameId值看起来很可疑。

frameId值看起来很有希望。如果我们知道框架的frameId，我们可以使用它来过滤请求吗？

可能，但frameId值在浏览器扩展中并不是唯一的。
我创建了另一个相同的扩展名，并获得了它的后台iframe来加载相同的url。它生成了一个相同的外观请求，具有相同的frameId（对于它自己的 - 但不同的iframe）。
此外，此Chromium问题涉及frame id collisions： https://code.google.com/p/chromium/issues/detail?id=173325

解决方案

事务状态

嗨 - 通过类似的问题挣扎，以下是我找到的：

tabId 和 parentFrameId 值看起来很可疑。

查看

• tabId 被设置为-1。
由于扩展在它们自己的进程中，因此

• 0表示父级是您的顶级框架





使用 chrome.tabs 您实际上可以为后台页面获取一个tabId ，但不幸的是，正如您发现的那样，WebRequest始终为 tabId

一般来说，好像 WebRequest 将被弃用，以支持 DeclarativeWebRequest code>但后者的开发目前暂停。



潜在的真正解决方案：



我没有测试过这个，但它是可能的只有您的背景页面发出的请求才会提供给您，并且tabId为-1。您可以过滤这些信息。

哈克解决方案：
$ b

1. 将一个框架注入到具有已知目标URL的选项卡中的实际页面上。该网址甚至可以是您的扩展程序中可通过网络访问的网址，以避免发生冲突。


2. 扩展端跟踪生成该请求的tabId和frameId。


3. 在iframe中加载您感兴趣的实际页面（通过重定向或通过使iframe的内容成为页面中的另一个iframe）。
   
4. 使用存储的tabId和frameId（可作为请求parentId）来决定将哪些请求过滤器。

I'm writing a Chrome extension that periodically checks a web-page on the user's behalf. To be unobtrusive, the page is loaded into an iframe on the extension's hidden background page. Is it possible to identify just the web requests made by this iframe?

My initial experiments (see below) seem to indicate that this is tricky. Getting all web requests for a particular tab is easy: you have the tabId, and can filter web requests (via the WebRequest API) with that tabId. But for a background-page iframe, it's unclear what the "tabId equivalent" identifier is, or how to use it to filter web requests.

Any thoughts?

My initial experiment details are below. The frameId value looked promising, but I don't believe it's unique across extensions.

This question has already been asked for Firefox: Identify requests originating in the hiddenDOMWindow (or one of its iframes)

== Experiment ==

As an experiment, I:

• Listened for all web requests with the WebRequest API
• Created an iframe on the extension's background page, and opened a url.

Here's a captured iframe web request:

{
  "frameId": 2,
  "method": "GET",
  "parentFrameId": 0,
  "requestId": "11988",
  "tabId": -1,
  "timeStamp": 1395423892612.272,
  "type": "sub_frame",
  "url": "http://en.wikipedia.org/wiki/Frog"
}

The tabId and parentFrameId values look suspect.

The frameId value looks promising. If we knew the frameId of the frame, could we use that to filter requests?

Possibly, but the frameId value isn't unique across browser extensions. I created another identical extension, and got its background iframe to load the same url. It generated an identical looking request, with identical frameId (for its own - but different - iframe). Also, this Chromium issue refers to "frame id collisions": https://code.google.com/p/chromium/issues/detail?id=173325

解决方案

State of Affairs

Hi - struggling through a similar problem and here's what I've found:

The tabId and parentFrameId values look suspect.

Check out the documentation for the details object returned to WebRequest callback handlers:

• tabId is set to -1 when there's no tab (like in a background page).
• since extensions are in their own processes 0 indicates the parent is your top-level frame

Using chrome.tabs you can actually get a tabId for a background page but unfortunately, as you've found, WebRequest always gives -1 for a tabId

Generally, it seems as though WebRequest was going to be deprecated in favor of DeclarativeWebRequest but development of the latter is currently on pause.

Potential real solution:

I haven't tested this but it's possible that only requests made from your background page will be available to you and have a tabId of -1. You could potentially filter for these.

Hacky solution:

1. Inject a frame onto an actual page within a tab with a known destination URL. The URL could even be a web-accessible URL within your extension to avoid collision.
2. Extension-side keep track of the tabId and frameId that generated that request.
3. Within the iframe load the actual page that you're interested in (either via a redirect or by having the content of the iframe be another iframe to the page).
4. Use the stored tabId and frameId (available as the requests parentId) to decide which requests to filter.

这篇关于Chrome扩展程序：确定背景页面iframe的网页请求？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！