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 <[email protected]> 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. >
