On Wed, Feb 10, 2010 at 2:27 PM, Brian Candler <b.cand...@pobox.com> wrote: > On Wed, Feb 10, 2010 at 07:26:00AM -0800, Chris Anderson wrote: >> The problem with this approach, imho, is that currently users have the >> same set of roles in every db. That is, your userCtx doesn't change >> depending on the db you are accessing. I can see how adding that >> capability increases flexibility. But it's the sort of flexibility >> that I see having a nasty complexity tax. Eg: currently the /_session >> resource is server-wide. As soon as some roles are available on >> certain dbs and not others, we need to make it /db/_session which is >> misleading as you don't actually log into dbs, you log into the >> server. > > Yes this could be confusing, especially adding db-roles to system-roles. > > Maybe it's clearer to think of it as "groups" and "rights": > > * "groups" are what your user is a member of (in your global _session). > * "rights" are what you can do in a particular database. > * "rights" within a db can be assigned to individual users or to groups. > * The "_admin" group picks up "_admin" rights automatically on all dbs. >
I think what you say has merit, but it doesn't jibe with my understanding of our implementation in a logical way. I'm ready to ship the basic programming model we have - it maps cleanly onto the underlying infrastructure (less abstraction can be a good thing). I think the kinds of apps you want to write can work in the current model, and I hope the trade off for less abstraction (eg no _rev on the _security object) in favor of simplicity will turn out to be the right choice. I'd like to help you find an architecture that works for your app. Maybe db(s) per user + filtered _admin controlled replication, which also maps really cleanly to usage patterns. Thanks for all the feedback. > Regards, > > Brian. > -- Chris Anderson http://jchrisa.net http://couch.io
