Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • 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).

    • 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'

      • 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.

        • 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.