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
