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: http://wiki.apache.org/couchdb/Replication#line-207 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 <[email protected]> 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 <[email protected]> > wrote: > > > >> On 20 June 2012 22:22, Pulkit Singhal <[email protected]> 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 > >> > >
