Re: GRDDLing microformats with Greasemonkey

From: Alf Eaton <lists_at_hubmed.org>
Date: Fri, 26 Aug 2005 20:05:14 +0200

On 25 Aug 2005, at 18:34, Stefano Mazzocchi wrote:

> Alf Eaton wrote:
>
>> This was why I was asking about a trigger for getting RDF from
>> Javascript into Piggy Bank - the script ends up with the RDF/XML
>> as a DOM fragment or a data: URI, neither of which Piggy Bank
>> picks up, so I was trying to find the easiest way to get around
>> this (or maybe rewrite the script as a Piggy Bank screen scraper,
>> but that still ends up at the same situation after doing the XSLT
>> transformation).
>>
>
> Hmmm, I found myself in a similar situation for the DSpace scraper,
> I had a working xslt scraper but needed some more functinality and
> decided to port it to javascript.
>
> We currently don't have a method in the 'module' component that is
> available in the javascript scraper environment to pass a DOM
> fragment, but it would indeed be nice to have (as we could, for
> example, have parts of the scraper use xslt and others parts use
> javascript)
>
> As for giving a hook from greasemonkey to piggybank: greasemonkey
> goes a *LONG* way to make sure that you can't access anything from
> the internal mozilla infrastructure that wasn't given to you (and
> wrapped!).
>
> This means that you can't go inside the xpcom layer and fetch an
> instance of the piggybank component running because greasemonkey
> doesn't allow you to.
>
> What we *COULD* do, is to enable 'semantic-web-like' functionality
> inside your own piggybank so that your greasemonkey script can use
> HTTP POST to injest the RDF/XML via AJAX into your local store.
> This is trivial and we need it for the integration of Ryan's POI
> anyway.
>
> Two problems though:
>
> 1) we default to port number 1978, but in piggybank 2.1 the user
> will be able to change it (to avoid conflict with other software
> running on that port). If this port is changed, there is no way for
> the greasemonkey script to discover if the fact that no web server
> is listening on that port means that piggybank is not available or
> that is running somewhere else. It's also true that the
> greasemonkey script might ask you for a port number in case the
> default upload fails.
>
> 2) allowing 'POST' to inject into your piggy-bank allows pretty
> much any application running on your machine to perform this. This
> is already aa security concern for privacy (for example, on a
> system running multiple users, everybody can connect to 127.0.0.1
> even those logged in with another username than yours!! A way to
> solve this problem effectively is to have piggybank do all HTTP
> traffic authenticated, asking you for a password (which then
> mozilla can later remember just like it does with other web
> sites!). Again, this moves us to the previous point: the
> greasemonkey script user will have to ask you for this password in
> a dialog box before the script can communicate with the local
> piggybank (the same would be true for a semantic bank). Of course,
> we could configure this behavior so if you didn't think your
> 127.0.0.1 could be intruded (say in your own personal laptop) you
> could get away with this.

I'm worried that web pages would be able to silently post data to
Piggy Bank if the POST mechanism was allowed to happen in the
background. If POSTing loaded a page from within Piggy Bank with a
confirmation button (as the data import works now) that could work.

I can't think of a way round the port problem though - it might have
to be either a protocol handler (as edonkey uses with ed2k:// ) or
MIME handler (which I still think might be easiest). Actually,
setting Firefox as the handler for application/rdf+xml seems to make
it open RDF files and then they can be imported by Piggy Bank, which
solves my problem, or at least it would if Piggy Bank recognised
data:// URIs as well as http:// and file://.

alf.
Received on Fri Aug 26 2005 - 18:01:22 EDT