couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Anderson <>
Subject Re: Initial couchdb accounts feedback
Date Sun, 10 Jan 2010 03:09:08 GMT
On Sat, Jan 9, 2010 at 1:19 PM, David Goodlad <> wrote:
> On Sun, Jan 10, 2010 at 6:22 AM, Matteo Caprari
> <> wrote:
>> I agree that per-instance-sessions are nice and have cool
>> implications, but it means that if I want to run
>> applications that don't share users, I have to fire up two couchdb
>> instances. This is not a bad thing, just probably not
>> very convenient with the current init scripts.
> I had a bit of a think about this overnight (since I'll be running in
> this scenario). If there are dbs that shouldn't share users, perhaps
> you could prefix the role with the appname. ie: { roles:
> ["myapp1:editor"] }. Then once there are reader ACLs, you could test
> that the user included roles with the appropriate prefix.

There's something Damien suggested that I think answers this problem
and some of those Brian Candler raised.

Currently the validation function takes 3 arguments (newDoc, diskDoc, userCtx)

The plan is to add a 4th argument, which is a security object. It
would be per-app, and could allow a site (I'm thinking an office or
some other organization) to map from site-roles to app-roles. So in
the case of a hospital, you'd set up a mapping between various site
roles like R.N., M.D., orderly, etc, and application roles
(prescription-writer, prescription-filler, etc in the prescription

I'm not sure if this gets us 100% of the way there, but I think it
gets us at least 80%, without being too complicated.


> Now that I've given some more thought to this problem, I've come to
> the conclusion that if I implement my roles properly reader ACLs can
> handle every case that I've been able to come up with.
> Dave

Chris Anderson

View raw message