I know Greasemonkey scripts are automatically wrapped in anonymous functions isolated in some way in order to prevent them conflicting with scripts in the page.
Does the same happen with Chrome user-scripts?
Yes, Greasemonkey scripts are normally wrapped in an anonymous function. And, Chrome userscripts apparently are too.
But, more importantly, Greasemonkey scripts are usually1 wrapped in an XPCNativeWrapper sandbox, while Google Chrome converts userscripts into extensions, and they operate in an arena that Google calls an "isolated world"2.
So, you don't need to wrap your script code in anonymous functions for security purposes, they're already protected.
Just beware that:
If you inject code directly into the page (create a <script> tag), then that code can be seen by the page's JS.
If you use unsafeWindow, then the page could theoretically follow it back and gain slightly elevated privileges.
The risk is very low, and I haven't been able to find any documented exploits in the wild.
~~~
Bottom line, scripts are isolated to different degrees in both browsers. (And not merely by being wrapped in anonymous functions.)
Greasemonkey has a nice set of privileged features available, in Firefox. While userscripts in Chrome are much more restricted.
However, much of GM's functionality is restored to Chrome via use of the Tampermonkey extension.
1 As of Greasemonkey version 1.0 (August 24, 2012), the sandbox is controlled by the #grant directive. If the script runs with (or defaults to) #grant none, then the sandbox isn't used. The script merely runs in a private scope and the normal GM_, API functions will not work.
2 Doesn't that sound so much bigger/nicer than some nasty sandbox? (^_^)
.
Related
I have a Selenium Java library that includes a JavaScript "glue" library that enables JavaScript functions to throw serialized Java exceptions. This enables much more natural handling of exceptional conditions without a lot of boilerplate.
Prior to executing a script that may want to throw an exception, I inject this library into the target page in a closure via executeScript. Upon return, the functions defined in the closure persist on the page, available for scripts that execute afterward to use for throwing exceptions.
This technique works as expected on HtmlUnit, Chrome, and Edge. However, the enclosed functions don't persist when I use this technique on Firefox. If I paste the closure into the multi-line editor in Developer Tools, the functions are retained, but this isn't a strategy I can use in Selenium Java automation.
Is there a different method I can use to add functions to a web page on-the-fly? Is there a Firefox setting that might allow the technique I'm using to work as expected?
The source for the script I'm using now can be found here: https://github.com/sbabcoc/Selenium-Foundation/blob/master/src/main/resources/javaGlueLib.js
As indicated in the comments, the structure and "namespace" functionality of the closure was obtained from here: https://github.com/jweir/namespace/blob/master/namespace.js
I found my answer. I always knew that my original implementation was drawing outside the lines, and Firefox won't let me get away with that.
The solution is to create a script element, set the [textContent] of this element to my original script source, and attach this new script node to the head element of my target page.
var head = document.getElementsByTagName('head')[0];
var script = document.createElement('script');
script.textContent = arguments[0];
head.appendChild(script);
This maybe a limitation of Firefox itself. But I am only guessing.
Have you tried a Man in the Middle proxy? such as https://mitmproxy.org
You will need to be in an environment where your test browsers can trust the MITM certificate. Then you can configure the MITM server to inject whatever you want into the requests.
The advantage of a MITM is will be browser agnostic.
Another option might be to use GreaseMonkey for Firefox.
https://addons.mozilla.org/en-US/firefox/addon/greasemonkey/
Userscripts are used by add-ons like Greasemonkey. But how can I utilize these scripts in my site?
For example, I found a script could eliminate ads in videos, and I want to put this script in my site, so people in my site wont't see those ads
I've tried just to save and put it in <script> in the head, but something just went wrong.
(TypeError: document.body is null)
I also tried to put it just before </body>, no error reported this time, but something still doesn't work.
And I'm wondering how Greasemonkey works? Does it just insert scripts in the webpage? How does it load scripts into the pages?
Greasemonkey and Userscripts.org are meant to provide kind of lightweight extensions for the browser, not for the webpages. I.e. you install them as the user inside your browser.
Some of the trivial scripts might be incorporated into webpages, but in general, Greasemonkey has some "superpowers" to do things that ordinary JavaScript can't do due to security constraints. For instance, issuing (and reading response of) cross-domain XMLHttpRequest, interactions between frames from different origin etc.
Normally Greasemonkey scripts are executed when DOMContentLoaded is fired by the browser (this can be changed using #run-at directive to execute the script before anything is loaded).
If the script has #grant none in its GM meta section, then it could be perhaps incorporated into your site, but it depends on what it exactly does.
Bear in mind also that Greasemonkey is a Firefox extension (there's equivalent extension for Chrome and also some limited native support from Chrome and Opera). Many userscripts will likely fail in IE8.
I have my own javascript that I need to test with Greasemonkey. I've never worked with Greasemonkey before; How do I test the script?
I am not testing it on the World Wide Web, I have saved the target page (Firefox > Save page as > Web page, complete), so I am testing it locally.
What is the process? How do I test the script?
Here are some guidelines for troubleshooting Greasemonkey scripts, both in general, and on local copies of webpages.
For testing on local pages (without a local web-server), you must change a setting of Greasemonkey.
Open about:config and set greasemonkey.fileIsGreaseable to true
Make sure the local copy of the webpage is not in the system's /tmp or /temp folder(s). The script will not work reliably, if it is.
Make sure the script source is not in the system's /tmp or /temp folder(s). The script will not install if it is.
For a script to work on local files, be sure you have an appropriate #include directive aimed at the local webpage copy. For example:
// #include file:///D:/web/local%20page%20copies/*
Familiarize yourself with Firefox's error console (CtrlShiftJ) and how it can be used to determine the source of errors in Greasemonkey scripts.
Install Firebug and get familiar with it. Firebug's excellent console functions work great from within a GM script -- although you might have to preface them with unsafeWindow..
Test as much of the javascript as you can, that doesn't use GM_ functions, in Firebug's JavaScript console first.
See also:
Troubleshooting for Script Authors
Avoid Common Pitfalls in Greasemonkey
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:
Runs scripts in an XPCNativeWrapper sandbox, unless #grant none is in effect (as of GM 1.0).
Wraps the script in an anonymous function by default.
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:
Runs scripts in an "isolated world".
Wraps the script in an anonymous function.
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:
The only way for non-Tampermonkey userscripts to access objects or functions provided by the target page.
Almost always fully compatible between Chrome, Firefox, Opera, etc. (IE is, as always, something else.)
Often easier to debug the whole script; developer tools work normally.
Injection drawbacks:
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.
Can cause side effects or conflicts with the page's JS.
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.
The page can see, use, change, or block the script.
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.
I've got a little problem with UserScripts in Google Chrome, to be precise with getting to the object window of an iframe. Very doable via the Google Chrome console, very impossible via the UserScript or so it seems so far. To be honest it seems as if it was on purpose, as if there was some reason why I'm not allowed to access other window objects.
document.body.innerHTML += "<iframe name='iframe'></iframe>";
console.log(top.frames.iframe);
console.log(window.frames.iframe);
console.log(unsafeWindow.frames.iframe);
console.log(document.getElementsByName('iframe')[0].contentWindow);
console.log(document.getElementsByName('iframe')[0].contentDocument.defaultView);
-->
chrome-extension://eelclpmekkanegjojjmaldeddncficoj/script.js:14 undefined
chrome-extension://eelclpmekkanegjojjmaldeddncficoj/script.js:15 undefined
chrome-extension://eelclpmekkanegjojjmaldeddncficoj/script.js:16 undefined
chrome-extension://eelclpmekkanegjojjmaldeddncficoj/script.js:17 undefined
chrome-extension://eelclpmekkanegjojjmaldeddncficoj/script.js:18 undefined
Might I ask what Chrome's problem is? I don't really get why should a UserScript have lesser access to javascript than a normal script, what are the implications? By the way, yes, the iframe is on the same domain and protocol. :(
UnsafeWindow isn't support by Chrome, try TamperMonkey, pretty sure it provides read-only access to that variable.
contentWindow.document isn't available for Chrome. contentDocument should work.
Also, XMLHttpRequest for cross domains also aren't supported. Most of these are for security purposes. Userscripts in Chrome are content scripts, they cannot access the functions/variables defined by web pages or by other content scripts. It's mostly for security and isolation of scripts, to prevent scripts from conflicting with each other.
As for document.getElementsByName('iframe')[0].contentWindow, I think it's because the way you're trying to add in your iframe. For starters, don't name your iframe as 'iframe', always a very bad practice.
Instead to attempting to add it into the body's innerHTML, use appendChild(), and append a new iframe object into document.body. Also, instead of document.getElementsByName, try document.body.getElementsByName.
I write greasemonkey scripts for firefox, and Chrome seems too restrictive. And I hope you know about the location hack for userscripts. Check out http://wiki.greasespot.net/Location_hack . You can use Javascript in your userscripts ;) And just to let you know right now, I would VERY much warn against messing with iframes and userscripts. I've wrote a script for Greasemonkey, been trying for 6 months, but somehow, when I involve code inside the iframe, half of the time, that result is undefined, and I never get into that problem with javascript. Also, if you inject .js script objects into a document from a userscripts, the new code is still somehow affected, and so how, randomly, elements show up as undefined. After 6 months of trying, I gave up, and I just have a bookmarklet just injects a .js script into documents manually. Of course, you don't have to do that, you can just use a location hack to inject the code from a userscript. But as for writing entire scripts based on userscripts for iframes, I'm staying far far away...