为什么window（和unsafeWindow）与用户脚本不同于< script>标签？ [英] Why is window (and unsafeWindow) not the same from a userscript as from a <script> tag?

问题描述

我在开发这个小用户。当我想用我的脚本阻止正在运行的网站上的每个 XMLHttpRequest 时，没有任何事情发生（至少在Chrome上）：

  function main（）{
 //用自定义函数覆盖XHR.open 
 window.XMLHttpRequest.prototype.open = function（）{
 //没什么......所以它应该阻止每个xhr.open（）调用
} 
} 
 main（）; 
  

用<$替换窗口时也是如此c $ c> unsafeWindow 。

然而，当我使用这个小技巧时，一切都像魅力一样：

  //不再调用main（），并且：
 var script = document.createElement（script）; 
 script.textContent =（+ main.toString（）+）（）;; 
 document.body.appendChild（script）; 
  

每次拨打 xhr.open 都会被取代通过我的自定义函数，不再需要AJAX。

所以我想窗口元素在<$时不一样从脚本内部调用c $ c> main ，而不是从< script>< / script> 容器中调用它。有人能解释一下为什么吗？

解决方案

参见Chrome用户脚本是否与全局命名空间分开，如Greasemonkey脚本？。 Chrome用户脚本/内容脚本和Greasemonkey脚本都与页面的javascript隔离。这样做是为了帮助您避免被黑客入侵，但它也可以减少冲突和意外的副作用。

但是，每个浏览器的方法都不同...... / p>

Firefox：

1. 在 XPCNativeWrapper沙箱，除非 @grant none 生效（从GM 1.0开始）。


2. 包装脚本默认情况下，在匿名函数中。


3. 提供 unsafeWindow 来访问目标页面的javascript。但请注意，敌对网站管理员可能要遵循 unsafeWindow 使用回到脚本的上下文，从而获得提升权限，以便与您进行对比。

Chrome：

1. 在孤立的世界中运行脚本。


2. 在匿名函数中包装脚本。


3. 严格 阻止对页面JS的任何访问脚本反之亦然。
   
   最近版本的Chrome现在提供了一个名为 unsafeWindow 的对象，但兼容性非常有限，但此对象不提供任何访问目标页面的JS。它与脚本范围中的窗口相同（页面范围中不是窗口）。

---

也就是说，使用 unsafeWindow的脚本版本应该在Firefox上工作。 可能使用Chrome上的 Tampermonkey扩展程序，但我我现在不打算再仔细检查。

当你这样做技巧时（ var script = document.createElement（script） ）; ... ），您 将 代码注入目标网页。这绕过了沙箱，是普通Chrome用户脚本与脚本JS进行交互的唯一途径。

注入优势：

1. 非Tampermonkey用户脚本访问目标页面提供的对象或功能的唯一方法。


2. Chrome，Firefox，Opera等几乎总是完全兼容（IE就像往常一样。）


3. 通常更容易调试整个脚本;开发人员工具正常工作。

注射缺陷：

1. 脚本，至少是注入的部分，不能使用 GM _ 提供的增强特权（特别是跨域）函数 - 尤其是 GM_xmlhttpRequest（）。
   
   请注意目前 Chrome仅支持 GM_addStyle ， GM_xmlhttpRequest ， GM_log 和 GM_openInTab 完全，原生。
   
   Tampermonkey几乎完全支持 GM _ 功能。




2. 可能会导致与页面JS的副作用或冲突。




3. 使用外部库会引入更多冲突和时序问题。它远不如 @require 那么简单。
   
   @require ，也运行外部JS来自本地副本 - 加快执行速度，但几乎不再依赖外部服务器。




4. 页面可以查看，使用，更改或阻止脚本。




5. 需要启用JS。特别是Firefox Greasemonkey可以在JS被阻止的页面上运行。这可能是臃肿，蹩脚和/或侵入性页面的天赐。

I was facing an issue while developing this small userscript. When I wanted to block every XMLHttpRequest from the running website with my script, nothing was happening (at least with Chrome):

function main() {
  // Override XHR.open with a custom function
  window.XMLHttpRequest.prototype.open = function() {
    // Nothing... so it's supposed to block every xhr.open() call
  }
}
main();

Same thing when replacing window by unsafeWindow.

However, when I used this little trick, everything worked like a charm:

// No more call to main(), and:
var script = document.createElement("script");
script.textContent = "(" + main.toString() + ")();";
document.body.appendChild(script);

Every call to xhr.open is replaced by my custom function, no more AJAX.

So I guess the window element is not the same when main is called from inside the script than when it's called from a <script></script> container. Can someone explain me why ?

解决方案

See "Are Chrome user-scripts separated from the global namespace like Greasemonkey scripts?". Both Chrome userscripts/content-scripts and Greasemonkey scripts are isolated from the page's javascript. This is done to help keep you from being hacked, but it also reduces conflicts and unexpected side-effects.

However, the methods are different for each browser...

Firefox:

1. Runs scripts in an XPCNativeWrapper sandbox, unless @grant none is in effect (as of GM 1.0).
2. Wraps the script in an anonymous function by default.
3. Provides unsafeWindow to access the target page's javascript. But beware that it is possible for hostile webmasters to follow unsafeWindow usage back to the script's context and thus gain elevated privileges to pwn you with.

Chrome:

1. Runs scripts in an "isolated world".
2. Wraps the script in an anonymous function.
3. Strictly blocks any access to the page's JS by the script and vice-versa.
   Recent versions of Chrome now provide an object named unsafeWindow, for very-limited compatibility, but this object does not provide any access to the target page's JS. It is the same as window in the script scope (which is not window in the page scope).

---

That said, the version of your script that used unsafeWindow should work on/in Firefox if implemented correctly. It might work using the Tampermonkey extension on Chrome, but I'm not going to double-check that right now.

When you do that "trick" (var script = document.createElement("script"); ...), you are injecting code into the target page. This bypasses the sandbox and is the only way on a normal Chrome userscript for a script to interact with the page's JS.

Injection advantages:

1. The only way for non-Tampermonkey userscripts to access objects or functions provided by the target page.
2. Almost always fully compatible between Chrome, Firefox, Opera, etc. (IE is, as always, something else.)
3. Often easier to debug the whole script; developer tools work normally.

Injection drawbacks:

1. The script, at least the injected parts, cannot use the enhanced privileges (especially cross-domain) provided by the GM_ functions -- especially GM_xmlhttpRequest().
   Note that currently Chrome only supports GM_addStyle, GM_xmlhttpRequest, GM_log and GM_openInTab, fully, natively.
   Tampermonkey supports GM_ functions almost fully, however.

2. Can cause side effects or conflicts with the page's JS.

3. Using external libraries introduces even more conflicts and timing issues. It's nowhere near as easy as @require.
   @require, also runs the external JS from a local copy -- speeding execution and all but eliminating reliance on an external server.

4. The page can see, use, change, or block the script.

5. Requires JS to be enabled. Firefox Greasemonkey, especially, can run on a page which has JS blocked. This can be godsend on bloated, crappy, and/or intrusive pages.

这篇关于为什么window（和unsafeWindow）与用户脚本不同于&lt; script&gt;标签？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！