On Mon, Feb 16, 2009 at 7:49 PM, Harish Mallipeddi <[email protected]> wrote: > On Tue, Feb 17, 2009 at 2:18 AM, Paul Davis > <[email protected]>wrote: > >> On Mon, Feb 16, 2009 at 1:02 PM, Damien Katz <[email protected]> wrote: >> > The problem with b) admin-enforced replication policies is that it's not >> > really possible. The replicator is just an agent of the user who invoked >> it, >> > it can choose to follow some rules set by the admin, or it follows it's >> own >> > rules. You can't give a user access to the database, but enforce that >> they >> > can only replicate it the admin specified way. If the user can perform a >> > certain update in the database using regular methods, he can also do so >> via >> > the replicator. >> > >> >> As we were mulling over the security considerations of allowing users >> to run arbitrary code on a CouchDB node, I had the idea to allow the >> node's admin to store a set of predefined methods that could be used >> as replication endpoints. As in, instead of posting a JS function, we >> post a {"filter": "foo/name"} member and it pulls the replication >> filter code from {"replication_filters": {"name": "function...."}} >> defined in "_design/foo". This way we have the full benefit of using >> JS to do our filtering while preventing arbitrary code execution. >> >> > This is exactly what I was thinking except I think you need a way to send > extra params to the filter function in this scenario since you're not > letting the user post any javascript filter function of his choice. > > Extra POST params (apart from the one specifying the name of the filter from > the design doc you want to apply) should be sent as args to the filter > function. That way an admin can install a design doc with a filter predicate > like so: > > _design/foo: > { "replication_filters": { > "name":"function(doc, userid) { if(doc.userid == userid) { return true; > } else { return false; } }" > } > } > > And then the client can do a POST to /_replicate/ with the following data in > order to fetch only that user's docs: > {"filter":"foo/name", "args":{"userid":"user1"}} >
This story sounds really promising. Admins should have the option to let users POST filters in (analogous to temp_views), but filters in design docs, coupled with query params, seems like an ideal way to balance flexibility and security. Chris -- Chris Anderson http://jchris.mfdz.com
