Yesterday I posted a GreaseMonkey script to add a CPAN Dependencies link to search.cpan.org.
The only problem with that is that FireFox is not my main browser. I tend to use FireFox for web development (FireBug++) and Safari for general surfing. Theoretically you can use GreaseMonkey scripts in Safari using CreamMonkey - but I couldn't get that to play nicely with Leopard.
So I've released HTTP::Proxy::GreaseMonkey which builds on BooK's excellent HTTP::Proxy to provide a local proxy that functions like GreaseMonkey.
Version 0.01 of HTTP::Proxy::GreaseMonkey has no support for the GM_* utility functions that the real GreaseMonkey provides - but it works well enough to support my CPAN dependencies user script and probably quite a few other GM scripts. Suggestions are welcome. Suggestions with patches even more so.
It also works with Yanick's RtSeverityOrdering. Anyone got any other Perl related GreaseMonkey scripts I can try it with?
As far as I can say, this approach can’t ever work really right, I’m afraid. Security is a big issue with Javascript, and the origin of code and content (in terms of DNS domain, mostly) plays a big role. There are tight limitations on what is permitted to code when things with different origins mix.
Now Greasemonkey runs scripts in the context of the page; however, it gives them access to functions that run within the browser’s local security context. That’s what’s special about GM_xmlhttpRequest: it runs in local security context and can therefore make requests for content in any domain, whereas XMLHttpRequest objects instantiated by remotely loaded code are restricted to sending requests to the domain the code was loaded from.
Sure, then, you can inject script into a page via the proxy to provide a GM_xmlhttpRequest function that replicates the bona fide GM_xmlhttpRequest’s interface. But the browser won’t know it’s trusted code and so won’t allow it to make requests anywhere else than where that proxy-injected code appears to have come from. Mashup user scripts that bring together data from disparate domains therefore won’t work.
So quite a few scripts can’t work – the more complex, the more likely to fail. And since the point of HTTP::Proxy::GreaseMonkey is that the browser knows nothing of its presence, that would seem to me to be unfixable.
Of course, a lot of scripts still will work, which makes the module worthwhile even if it’s unlikely to ever be an equivalent replacement for the browser extension(s).
Re:GM_xmlhttpRequest and other impossibilities
AndyArmstrong on 2007-12-17T12:16:12
Yes, but I have a proxy... That means I can write a GM_xmlhttpRequest with a specially formed URL which appears to fetch from the current domain but which the proxy rewrites to fetch from the intended domain.
http://this.domain.com/<some long string>/intended.com/something.xml -->
http://intended.com/something.xml
That's my theory anyway - I haven't implemented it yet. Can you see any problems with that? Obviously I'm opening up an XSS hole so I'd need to make sure that the GM_ functions weren't accessible to the page's original JavaScript. I think that can be achieved with a nested scope around the injected GM Javascript.
Re:GM_xmlhttpRequest and other impossibilities
Aristotle on 2007-12-17T18:04:12
Nice lateral thinking there!
It almost sounds too easy to be right, but at first glance I can’t see anything wrong with that. I’d use HTTP Auth credentials rather than a long string in the URI, but that’s just a quibble.
Re:GM_xmlhttpRequest and other impossibilities
AndyArmstrong on 2007-12-17T18:11:15
I've just released 0.03 which supports GM_xmlhttpRequest to arbitrary sites. I'm afraid it uses a long arbitrary string in the URL to alert the proxy at the moment. I'll have a think about using auth credentials instead - it certainly sounds cleaner.
