On Wed, 2009-01-14 at 14:01 -0700, zooko wrote: > Toby Murray wrote: > > It seems strange to require an unguessable (F)URL to join the grid > > but not one to consume space on it. > > You're right. > But in the meantime, it sure would make sense to have a way to give > people read-only access to a grid as a whole. > > One hack would be to use the fact that HTTP GETs can't be used to > cause side-effects on Tahoe. If you give someone access to a web > proxy which passes GETs through but rejects PUTs, POSTs, and DELETEs, > then they'll have read-only access to the whole grid.
This isn't quite the same thing. My basic objection is that there are operations in the wapi that provide any Internet connected machine with ambient authority to consume space on any publicly accessible grid. This seems dangerous and I can think of plenty of cases in which it could be problematic. Operations in the wapi that are problematic (i.e. that provide the user with ambient authority) include: PUT /uri POST /uri?t=mkdir PUT /uri?t=mkdir POST /uri?t=upload I'd prefer a design in which at the time that a grid is created, the introducer creates a single write-cap to a directory (the "root" of the grid). One then needs to use this writecap to add any content to the grid by creating other directories and files that live within them etc. I get that this is tricky in the current design since the operations listed above are needed to bootstrap the first content in a grid. I'll have a look at writing a patch to disable the methods above, perhaps via a command-line argument that can be passed when starting a node. This way, one can bootstrap a grid using these methods before taking it live and then, when making it publicly accessible, disable them so that the potential for further modification to a grid can then be controlled (by how capabilities have been distributed to its initial bootstrapped contents). As an aside: I assume that $DIRCAP in the operation POST /uri/$DIRCAP/[SUBDIRS../]?t=mkdir&name=NAME must a a write-cap to the directory, right? This is OK then. Finally, what does the following (not explained) operation do: POST /uri/$FILECAP?t=upload Does this update the contents of a mutable file? Cheers for the response Toby _______________________________________________ tahoe-dev mailing list [email protected] http://allmydata.org/cgi-bin/mailman/listinfo/tahoe-dev
