A thought.
The current security model requires you spread information in three places:
_readers (has access to database); _security (for controlling updates);
_admins (can update security and ddocs)
What if this was replaced by a single resource, _security, structured like
this?
{
"names":{
"foo":[],
"bar":["_admin"]
},
"roles":{
"baz":["doctor"]
}
"otherstuff"
}
You get reader access if your name or role appears as key in the relevant
section, regardless of the value. So [] means reader only. You get admin
access if the value contains "_admin". Other rights are available for the
application to use, and may affect validate_doc_update.
The reasons I propose this are as follows:
1. it's extensible without having to change the DB structure again
2. application-specific rights can be administered in the same way as
couchdb system rights
3. futon can display this clearly - a list of names and a list of roles,
each with their rights shown next to it
4. a hash key is quicker to look up for access control than an array scan
However it retains the current fundamental design, which is that the rights
are stored in a resource within the database, which is not a document.
Thoughts?
What I've really done is to flip things around, so that
"readers":["name1","name2"]
"admins":["name3"]
becomes
{"name1":["reader"], "name2":["reader"], "name3":["admin"]}
But doing that also makes it easier to add a future auth model where rights
are stored in a more scalable way (e.g. as separate user documents or in an
external LDAP database), where such information is keyed by username or
role.
Regards,
Brian.
