On Sun, 2009-01-18 at 11:30 -0700, zooko wrote: > Thanks, Toby! > > I applied your patch, [3440], and I have the following comments or > requests about it: > > 1. Please add doc to http://allmydata.org/trac/tahoe/browser/docs/ > configuration.txt about this option. Possibly in http:// > allmydata.org/trac/tahoe/browser/docs/frontends/webapi.txt as well.
Will do. > 2. Do I understand correctly that this prevents people from doing > any PUTs or POSTs to URLs that begin with "uri/"? No. It (should) prevent people from doing PUTs and POSTs only to URLs whose path is "/uri" -- not to URLs that contain caps. > That seems just > about right -- it prevents adding new files or changing the contents > of files even if you know the write-cap to a file or a directory. No. It prevents adding new unlinked files or creating new unlinked directories. This is because these operations do not require a capability. Hence they provide ambient authority to anyone that can create an HTTP connection to your node. Hence, "ambient_upload_authority" -- maybe this should be called "ambient_create_authority" but I don't think the name is a big deal. I'll embellish the current test code to save one of the URLs returned from a create-unlinked-directory operation and then test that once web.ambient_upload_authority = false, we can still upload files and create subdirs of that directory. Could you confirm my manual test results (just performed while writing this email) that web.ambient_upload_authority = false does indeed allow one to upload new files and create new sub-directories provided one has a write-cap to a directory. > But what about the check, verify, repair, manifest, and stats > commands listed at the end of webapi.txt. These operations all require a $URL or $DIRURL, neither of which have been defined. If these are caps, (are they verify-caps?) then that seems fine. > I'm not 100% sure why we > made these available through POST instead of through GET -- perhaps > because they have the "side effect" of causing a potentially large > amount of CPU, network, and disk work even though they don't have any > "side effects" on the filesystem graph of directories and files. > Currently, if web.ambient_upload_authority is false then you can't do > those check, repair, etc. operations. Is that what you intend? No. These operations should still work with web.ambient_upload_authority = false, since they require a cap and therefore are not providing ambient authority. > 3. Maybe for the test we could use du() from fileutil (http:// > allmydata.org/trac/tahoe/browser/src/allmydata/util/fileutil.py , > also known as http://allmydata.org/trac/pyutil/browser/pyutil/pyutil/ > fileutil.py ) to assert that the filesystem usage on the server isn't > greater after the client attempted to upload something. I'll look into this. Cheers Toby _______________________________________________ tahoe-dev mailing list [email protected] http://allmydata.org/cgi-bin/mailman/listinfo/tahoe-dev
