incubator-couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robert Newson <>
Subject Re: Replication and validate_doc_field
Date Thu, 21 Jun 2012 10:01:34 GMT

The replicator does not inherently have admin privileges (this would make our security model
redundant). It has the privileges of the user you run it as, and can do only the things that
that user can. This is why, for example, it's possible that design documents don't get replicated,
because that requires _admin privilege on the target. Thus, there is no mystical interaction,
the replicator is just a normal user automating the task of ensuring all changes from a source
db are copied to a target db. To get a 401 means that the value in your "target" field did
not include authentication details (or included incorrect authentication details) and that
your target server has require_valid_user set to true.


On 21 Jun 2012, at 01:57, Pulkit Singhal wrote:

> Right, so what I'm saying is that the replicator client is being run with
> the creds of a super-duper-admin who inherently has _admin privileges.
> When the same code is run against a DB without any reader roles, everything
> works out. But when it is run against a DB with a reader role, it fails.
> I'm hoping that someone will clarify the security constraints around how
> replication behaves with db level security in 1.2.0
> I already read the following tidbit in the wiki:
> But it has more to do with the replicator DB itself rather than the DB
> being replicated so I'm hoping someone can shed some documentation-worthy
> light on how security works around a DB being replicated.
> On Wed, Jun 20, 2012 at 5:03 PM, Robert Newson <> wrote:
>> The replicator is just a client, so if your validate_doc_update doesn't
>> allow it to update, it won't be able to update.
>> That said, 401 means you failed to pass a valid user:pass combination. You
>> failed to *authenticate*, though the standard description of 401 is
>> notoriously misleading.
>> B.
>> On 20 Jun 2012, at 22:38, Pulkit Singhal wrote:
>>> Thanks for pointing out that mis-type, I was indeed referring to
>>> validate_doc_update.
>>> And I'm familiar with the wiki links and the general instructions around
>> it
>>> as well.
>>> Perhaps I should explain the motivation behind this question.
>>> When I attempt to replicate from CouchDB 1.2.0 to TouchDB (another
>> flavor),
>>> I receive:
>>> error (
>>>   401,
>>>   "401 unauthorized"
>>> )
>>> A little bit of trial and error showed that as long as I did NOT set
>>> member-roles or member-names on the DB level security in futon ...
>>> everything worked fine.
>>> So now have to wonder why this happens, why would db-member-level
>> security
>>> prevent an _admin from replicating? My 1st guess was that perhaps
>>> validate_doc_update somehow now has a hand in replication as well so I
>> just
>>> wanted to check ... if that is not the root cause here then what could it
>>> be?
>>> On Wed, Jun 20, 2012 at 3:34 PM, Dave Cottlehuber <>
>> wrote:
>>>> On 20 June 2012 22:22, Pulkit Singhal <> wrote:
>>>>> Does validate_doc_field method affect replication authN or authZ for
>>>>> CouchDB 1.2.0?
>>>> Hey Pulkit,
>>>> I googled authN/Z and found authorisation and authentication. I checked
>>>> the source and there's no validate_doc_field.
>>>> A validate_doc_update function (VDU) is run on a single doc only, and
>>>> has access to the proposed new doc as well as the current on-disk
>> version,
>>>> and the user context.
>>>> So you can tell if the submitter of the update is authenticated or not,
>> and
>>>> you can use couchdb roles, or other custom javascript fields in your doc
>>>> to decide to reject the docs or not.
>>>> There's more info on both the wiki and the definitive guide on this too.
>>>> A+
>>>> Dave

View raw message