Thanks Robert, Simon & Dave! Its always difficult to realize that if the conclusion doesn't fit then the assumption must be wrong. I was assuming that my TouchDB/CouchCocoa replicator client had been passing the credentials of a remote_admin_user to the remote_url all along but it turns out that this was simply a false assumption.
Thanks to your explanation I could work back and figure out that the creds had never been included before in a call and the db had always been open to replication by anyone at all! Putting the reader role in was a stroke of luck that should have helped me see this grave mistake right away ... but instead I started blaming it for my troubles ... LOL, thanks for straightening out my basics. Cheers, - Pulkit On Thu, Jun 21, 2012 at 5:01 AM, Robert Newson <[email protected]> wrote: > > 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. > > B. > > > 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: > > 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 > >>>> > >> > >> > >
