From user-return-15421-apmail-couchdb-user-archive=couchdb.apache.org@couchdb.apache.org Thu Mar 24 23:02:37 2011 Return-Path: Delivered-To: apmail-couchdb-user-archive@www.apache.org Received: (qmail 89012 invoked from network); 24 Mar 2011 23:02:37 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 24 Mar 2011 23:02:37 -0000 Received: (qmail 13812 invoked by uid 500); 24 Mar 2011 23:02:34 -0000 Delivered-To: apmail-couchdb-user-archive@couchdb.apache.org Received: (qmail 13776 invoked by uid 500); 24 Mar 2011 23:02:34 -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 13768 invoked by uid 99); 24 Mar 2011 23:02:34 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 24 Mar 2011 23:02:34 +0000 X-ASF-Spam-Status: No, hits=2.9 required=5.0 tests=FREEMAIL_FROM,FS_REPLICA,RCVD_IN_DNSWL_LOW,SPF_PASS,T_TO_NO_BRKTS_FREEMAIL X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of mrtrick@gmail.com designates 209.85.210.180 as permitted sender) Received: from [209.85.210.180] (HELO mail-iy0-f180.google.com) (209.85.210.180) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 24 Mar 2011 23:02:26 +0000 Received: by iyf40 with SMTP id 40so693609iyf.11 for ; Thu, 24 Mar 2011 16:02:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=2ZE9aNXnjMS1yOE79qXvulFtvYg6f4PXa6QK0w19t8I=; b=u8JACIseVLfrbPX+rkMx162Ce4CYJAO/TvjaBWHEPsTyjsbruuPDSyQGT2lfs9aIlf OWfQ47O5KHcv6KQ8Sj6bCk1SG5ZJwMPpWo6ZUaXtrIuiqtV2UIRzgqdDbkc2n+T0I+Ku dn4udaMko9lqmcB3DCxJ9kof9BjoIfrXMjqWU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; b=J7gl0v+2SFISx98TNKvYh/m4pTCr69kZezJXEUPuxDrZLaYwr2PcL8UkeyJG/tsHl1 xRZaloMhx+pHmqdY5CQk1FMGdxjZdMaMa0czQ//Fw1qyPVz8SINLk/P3ZCw/h3tJsTjK NdKqlG2Jy/69k8VZi5AGEcUvHjWwlUhnrmpco= Received: by 10.42.75.133 with SMTP id a5mr74348ick.288.1301007725777; Thu, 24 Mar 2011 16:02:05 -0700 (PDT) Received: from [138.25.47.215] (eng047215.eng.uts.edu.au [138.25.47.215]) by mx.google.com with ESMTPS id vx7sm201998icb.14.2011.03.24.16.02.04 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 24 Mar 2011 16:02:05 -0700 (PDT) Message-ID: <4D8BCD50.8080003@gmail.com> Date: Fri, 25 Mar 2011 10:01:36 +1100 From: Patrick Barnes User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: user@couchdb.apache.org Subject: Re: Question about validator functions and replication References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org You're quite right, it would fail on replication. (And if you identified that issue solely from a hypothetical standpoint, well done) The solution could be to give your replication user as 'replication' role, and have the validator function look something like: function(newDoc, oldDoc, userCtx) { function to_object(arr) { obj = {}; for(var k in arr) obj[arr[k]] = true; return obj; } if (newDoc.author) { if(newDoc.author != userCtx.name and !('replication' in to_object(userCtx.roles))) { throw("forbidden": "You may only update documents with author " + userCtx.name}); } } -Patrick On 25/03/2011 4:46 AM, Nebu Pookins wrote: > Hi, > > I'm reading "CouchDB The Definitive guide", and in the chapter on > "Security" (http://guide.couchdb.org/editions/1/en/security.html), > they give an example of how to limit write-access to certain documents > based on its owner. The example validator function they give is: > > function(newDoc, oldDoc, userCtx) { > if (newDoc.author) { > if(newDoc.author != userCtx.name) { > throw("forbidden": "You may only update documents with author " + > userCtx.name}); > } > } > } > > If I understand correctly, userCtx is based on the HTTP request of the > POST/PUT/DELETE request which is trying to modify some document: If > I'm logged into couch, either via HTTP basic authentication, or > cookies, or something along those lines, then my username will show up > in the userCtx, and we simply do a string comparison to see if I'm the > "author" of a given doc, and if so, then the business rule is that I > should be allowed to change the doc. > > Elsewhere in the documentation, it mentions that validator functions > are run not only when POST/PUT/DELETE requests are made, but also when > replication occurs. What I'm confused about is what the value of > userCtx would be during replication. To give a more concrete example: > > Let's say we have 2 couchDB servers running, called Server 1 and > Server 2, and they've replicated with each other so that they both > contain identical data: a set of blog posts. > > A user "Alice" logs onto server 1, and edits one of her blog posts. > The validator function runs, and given that it's Alice that's logged > on, the validator function checks that the blog post's "author" field > is Alice, and assuming it is, it allows the update to occur. > A user "Bob" also logs onto the same server, edits one of his blog > posts, and again the validator allows it. > Then both users log off, and go do something else (e.g. watch a movie, > read a book, etc.) > > Now replication occurs: Server 2 will ask server 1 for a list of > changes, and server 1 will report that two blog posts have been > changed. > > Given that neither Alice nor Bob are connecting to server 2, it would > seem that the userCtx variable would not contain either of their > names, and thus the validation would reject the change, and > replication would fail. > > i figure I must be misunderstanding something about how either > validation or replication works, but I can't seem to figure out what > from the documentation. Can someone help clarify this for me? > > Thanks, > Nebu >