Mailing-List: contact user-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@couchdb.apache.org
Received-SPF: pass (athena.apache.org: domain of adam.kocoloski@gmail.com
 designates 209.85.221.181 as permitted sender)
Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes
Mime-Version: 1.0 (Apple Message framework v1076)
Subject: Re: all_or_nothing=true and replication
From: Adam Kocoloski <kocolosk@apache.org>
In-Reply-To: <20091103094308.GC9729@uk.tiscali.com>
Date: Tue, 3 Nov 2009 09:44:44 -0500
Content-Transfer-Encoding: 7bit
Message-Id: <D4B078DE-30AF-4354-90A1-9FB2F9D4D148@apache.org>
References: <01DCAC9E-0125-46EA-876E-12B685C40DFC@apache.org>
 <20091103094308.GC9729@uk.tiscali.com>
To: user@couchdb.apache.org

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,

Adam