couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Damien Katz <>
Subject Re: Partial replication -orelse- sending interpreted data to another server
Date Mon, 16 Feb 2009 18:29:11 GMT

On Feb 16, 2009, at 1:18 PM, 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.

Yes, that's a excellent idea I hadn't thought of. I think that solves  
a lot of problems.

Also, something I didn't mention before, the selective replication  
code isn't something that actually needs to occur server side. It's  
just way more efficient if it does. Client replicators could just pull  
everything and filter it client side. Server side filters are just an  


View raw message