couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Adam Kocoloski <>
Subject Re: all_or_nothing=true and replication
Date Tue, 03 Nov 2009 14:44:44 GMT
On Nov 3, 2009, at 4:43 AM, Brian Candler wrote:

> On Sun, Nov 01, 2009 at 05:36:18PM -0500, Damien Katz wrote:
>> Yes, you can make a situation where somehow a user has legal  
>> updates to
>> certain conflicts, but not others, on a particular node A. On some  
>> other
>> node B, somehow the security was different and he was allowed to  
>> update
>> all the docs. Then an attempt to merge all the conflicts into the
>> document the user didn't really have edit access too will not be
>> replicated from node B to node A.
>> It's a contrived situation, but possible with misconfigured or  
>> updated
>> security settings that haven't propagated.
> This is definitely something that I need to add to the
> Replication_and_conflicts page.
> When you talk about security mechanisms, I know of  
> "validate_doc_update",
> but are there other things which can affect whether a document is  
> replicated
> or not? (e.g. I've heard talk of a filtered _changes feed, I don't  
> know if
> that's implemented yet). I'd like to make sure I cover all bases.

Filtered _changes feeds have been implemented, although Benoit noted a  
problem with the continuous version.  The replicator doesn't yet know  
how to consume them, but it will soon.

> On a related point: is it possible to configure a database to stop  
> people
> *pulling* certain documents? For example, if I want to allow people  
> to read
> and replicate user documents but not _design documents?

Not at the moment.  We've had some proposals for document-granularity  
ACLs.  The sticking point often ends up being the view indexing --  
e.g. what privileges does it have, and how do we keep it from exposing  
data that would otherwise be restricted from a user? Best,


View raw message