[Tickets #2565] Re: Gecko Bookmarks extension

bugs at bugs.horde.org bugs at bugs.horde.org
Sat May 26 00:23:32 UTC 2007


DO NOT REPLY TO THIS MESSAGE. THIS EMAIL ADDRESS IS NOT MONITORED.

Ticket URL: http://bugs.horde.org/ticket/?id=2565
-----------------------------------------------------------------------
 Ticket             | 2565
 Updated By         | joey at joeyhewitt.com
 Summary            | Gecko Bookmarks extension
 Queue              | Trean
 Type               | Enhancement
 State              | Feedback
 Priority           | 2. Medium
 Owners             | 
-----------------------------------------------------------------------


joey at joeyhewitt.com (2007-05-25 17:23) wrote:

>> It would.  I had a reason for deciding against implementing JSON-RPC
>> (pretty much the only RPC-over-JSON standard I saw.)
>> (http://json-rpc.org/wiki/specification)  Now I'm not sure why, but I
>> think it may be that the newest version is still being written up in
>> specification.  I'll look at it some more.
>
> The spec looks good.

Yeah, on second glance it's alright.  I think I've finished implementing
the backend, but I haven't tested with a real JSON-RPC client yet.  I'll
probably adapt an existing JSON-RPC library to use Horde's AJAX/JSON
stuff, and use that for my extension.

As for security, I think the point is moot, now that the only way anything
useful can be retrieved is with a POST, and nobody should be able to forge
and read with POST, right?

>
>>> Regarding the AJAX and JSON stuff inside the XPI, I suggest that you
>>> use prototype that we use anywhere else in Horde. The most recent
>>> version has support for a CSRF protection built in.
>>> Heck, we could even build the XPI on the fly including the source
>>> files directly. Much easier than rebuilding the XPI anytime you
>>> change something. I plan to do this for IMP since ages.
>>
>> This sounds like a good idea to look into.  Where is the source?
>
> In my head. But it shouldn't be too hard. We have the Horde_Compress 
> library that we already use to create ZIP files on the fly. We should 
> probably put the XPI contents under trean/lib/XPI or 
> trean/templates/xpi with the same layout like in the XPI file, for 
> better maintainability.

Well, actually, I don't have to re-compress for my own development because
there's a way to point Firefox at a directory and it works just like an XPI
had been installed there.  But if I understand what you're saying, it would
be neat.  The XPI could be downloaded from the Horde server, which would
allow us to throw in some subtle features like making the XPI's default
server URL be the server you're downloading from.  (Perhaps that would not
be desirable, though.)  Is that what you meant?



More information about the bugs mailing list