On Wed, Jan 13, 2010 at 2:35 PM, David Goodlad <[email protected]> wrote: > Hi all > > I'm toying with the recently-updated auth code (good work Chris!), and > am considering making some small changes to te default validation > function in the _auth design document. These changes are specific to > my application. Is it reasonable to make changes to that doc and > assume that it won't be overwritten by couch? > > The changes I'm making might also be useful to others, so I'll > describe them here. > > In my application, there are many databases, one for every 'business'. > A business will have many users, of which at least one is a 'manager' > who is essentially an admin for that database only. If the business's > database name is "foobar", then the manager's user document in _users > would have a role "foobar:manager". In my validation functions in the > business database I check for roles prefixed with userCtx.db. > > I need to allow managers to add other users, including other managers, > to the business, so I'm planning to modify the validation function in > the users database to allow managers to modify roles with the same > prefix as their database name. > > Does this sound like a reasonable plan?
This sounds reasonable, but maybe we can make it easier. You could almost model the manager as a db_admin, but you probably don't want them editing design documents. So what you need is a set of roles that apply to particular users, in the context of a particular database. Maybe it makes more sense to store the db-roles within the db itself? I think this is the use case for the security object. (Just a 4th argument to the validation function, which is a document loaded from the database the validation runs from) We should ask Damien to weigh in on the _namespace to use for the document (should it be local?), and how to store the info. Glad to have you on the list, Dave. Chris > > Dave > -- Chris Anderson http://jchrisa.net http://couch.io
