On Sun, Jan 17, 2010 at 11:08:24AM -0800, Chris Anderson wrote: > > I like the naming, but not the 'only be updated by admins' part. If > > there were the concept of admins for individual dbs, I would be fine > > with it, though. > > There are db_admins. They are the ones who can install ddocs. So it > makes sense that they'd have exclusive access to the security object.
I wonder if there are two orthogonal things here: * people who can install ddocs (= the app developer) * people who can add roles to users in this db (= the app primary user) That is: if I am the primary user of a database, and I want to grant read access to persons X, Y and Z, I don't want to have to involve the app developer, nor the server administrator. Taking the prescriptions couchapp example again: * the app developer modifies design docs to set up view behaviour and app HTML server to the browser * the health services manager grants access to individual doctors and nurses (but is not a programmer and shouldn't be allowed to touch design docs) > > Perhaps it could be part of the _security/* namespace - eg > > _security/readers ? > > The current db-admins are not in a document (they are part of the db > file) so I don't want to go change all that and I think it's best to > have parallel interfaces for db-readers and db-admins. It's quite likely I'm being dense here, or missing something important. >From what I can gather, the security object will be usable for quite fine-grained control in validate_doc_update (e.g. a doctor can create a new prescription; a pharmacist can add notes to a prescription and mark it as fulfilled, but not change the recipient's name) Isn't "being able to read documents in the database" a similar capability? Couldn't the presence or absence of a user in the security document be used to allow or deny access to the database as a whole? Regards, Brian.
