couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Anderson <>
Subject Re: Partial replication -orelse- sending interpreted data to another server
Date Tue, 17 Feb 2009 04:05:04 GMT
On Mon, Feb 16, 2009 at 7:49 PM, Harish Mallipeddi
<> wrote:
> On Tue, Feb 17, 2009 at 2:18 AM, Paul Davis <>wrote:
>> On Mon, Feb 16, 2009 at 1:02 PM, Damien Katz <> 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 Anderson

View raw message