From user-return-21311-apmail-couchdb-user-archive=couchdb.apache.org@couchdb.apache.org Thu Jun 21 00:57:46 2012 Return-Path: X-Original-To: apmail-couchdb-user-archive@www.apache.org Delivered-To: apmail-couchdb-user-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id AAD30C198 for ; Thu, 21 Jun 2012 00:57:46 +0000 (UTC) Received: (qmail 10899 invoked by uid 500); 21 Jun 2012 00:57:45 -0000 Delivered-To: apmail-couchdb-user-archive@couchdb.apache.org Received: (qmail 10859 invoked by uid 500); 21 Jun 2012 00:57:44 -0000 Mailing-List: contact user-help@couchdb.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: user@couchdb.apache.org Delivered-To: mailing list user@couchdb.apache.org Received: (qmail 10851 invoked by uid 99); 21 Jun 2012 00:57:44 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 21 Jun 2012 00:57:44 +0000 X-ASF-Spam-Status: No, hits=1.5 required=5.0 tests=FSL_RCVD_USER,HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of pulkitsinghal@gmail.com designates 74.125.82.54 as permitted sender) Received: from [74.125.82.54] (HELO mail-wg0-f54.google.com) (74.125.82.54) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 21 Jun 2012 00:57:39 +0000 Received: by wgbfg15 with SMTP id fg15so57386wgb.23 for ; Wed, 20 Jun 2012 17:57:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=9ZyT0X2iASdkT9Sz6MVZ68F+1otwzfaJ6xYMRi5qIKg=; b=yq+ZYu6y4m0HISz/eCuOL+5x0aodW9egC7texh7tmkmbqOoixfGtcdDMxvMMbIZIEs fu2GLu274ZUNddodOHUV5C0hJGz8LUSsw2k4XjEDb9grmNcfLaTdzOG/I1P3ngIsOeEx 74om7hsskXcdBZDXV1gLMl4MMvKsONyM1yWZt7DB0o0H6CI06pHwEEmqwKHGCSO1hW2E lpSThat9t3LqBReVJKR6TrHbFNodIks0PHN9KPKatrvq1GH9a6oYjToU0ATb0/yQBV4P a/lG5Mo3hRgpEgUUO6BXb7f1iPNtNZzbeR0c3eFrW6Ao3mZOeideXmq8gYc1r+c65DhF prmg== MIME-Version: 1.0 Received: by 10.216.196.166 with SMTP id r38mr12383765wen.161.1340240238151; Wed, 20 Jun 2012 17:57:18 -0700 (PDT) Received: by 10.216.192.72 with HTTP; Wed, 20 Jun 2012 17:57:18 -0700 (PDT) In-Reply-To: <57FA970C-94DA-4804-A07D-B5734ACE5632@apache.org> References: <57FA970C-94DA-4804-A07D-B5734ACE5632@apache.org> Date: Wed, 20 Jun 2012 19:57:18 -0500 Message-ID: Subject: Re: Replication and validate_doc_field From: Pulkit Singhal To: user@couchdb.apache.org Content-Type: multipart/alternative; boundary=0016e6dbdea04f061f04c2f0ff74 X-Virus-Checked: Checked by ClamAV on apache.org --0016e6dbdea04f061f04c2f0ff74 Content-Type: text/plain; charset=UTF-8 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 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 > >> > > --0016e6dbdea04f061f04c2f0ff74--