Return-Path: Delivered-To: apmail-couchdb-dev-archive@www.apache.org Received: (qmail 75056 invoked from network); 2 Dec 2010 13:46:10 -0000 Received: from unknown (HELO mail.apache.org) (140.211.11.3) by 140.211.11.9 with SMTP; 2 Dec 2010 13:46:10 -0000 Received: (qmail 83178 invoked by uid 500); 2 Dec 2010 13:46:09 -0000 Delivered-To: apmail-couchdb-dev-archive@couchdb.apache.org Received: (qmail 83040 invoked by uid 500); 2 Dec 2010 13:46:09 -0000 Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@couchdb.apache.org Delivered-To: mailing list dev@couchdb.apache.org Received: (qmail 83032 invoked by uid 99); 2 Dec 2010 13:46:08 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 02 Dec 2010 13:46:08 +0000 X-ASF-Spam-Status: No, hits=2.2 required=10.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_NEUTRAL X-Spam-Check-By: apache.org Received-SPF: neutral (athena.apache.org: local policy) Received: from [74.125.82.180] (HELO mail-wy0-f180.google.com) (74.125.82.180) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 02 Dec 2010 13:46:02 +0000 Received: by wyb29 with SMTP id 29so3550363wyb.11 for ; Thu, 02 Dec 2010 05:45:40 -0800 (PST) MIME-Version: 1.0 Received: by 10.216.78.212 with SMTP id g62mr215978wee.78.1291297539877; Thu, 02 Dec 2010 05:45:39 -0800 (PST) Received: by 10.216.25.13 with HTTP; Thu, 2 Dec 2010 05:45:39 -0800 (PST) In-Reply-To: References: Date: Thu, 2 Dec 2010 08:45:39 -0500 Message-ID: Subject: Re: Per Document Filtering/Authorization From: Chad George To: dev@couchdb.apache.org Content-Type: multipart/alternative; boundary=000e0ce0494029ee0b04966da365 --000e0ce0494029ee0b04966da365 Content-Type: text/plain; charset=ISO-8859-1 I'm not sure purely ACL based authorization is sufficient since it makes it difficult to authorize specific documents to specific users. A function that has access to both the request context (user) and document seems more flexible. Also, I'm not sure I see a benefit in having the security stuff in a separate database. It makes things more difficult to replicate an entire application since the logic would be split between two databases. Having the authorization functions defined on the design document seems simpler. - Chad On Wed, Dec 1, 2010 at 10:38 PM, David Pratt wrote: > A couple of small clarifications: > > > My thought is that we might wish to implement a special _authorization > > database (or give it some flexible name similar to _users) that is not > > under MVCC rules. > > To be clear, all I mean by this is that whatever we call the db, you > ought to be able to give it a different name in the configuration in > the same way you can with the _users database. > > > In this scenario, a key in the _authorization database corresponds to > > the _type. _authorization could use a naming convention to _users that > > makes it special. > > Sorry this should have read: > _authorization could use a similar naming convention to _users that > makes it special. > --000e0ce0494029ee0b04966da365--