> 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).
With respect, I think we're actually talking about the same thing :-)
You've already said that it may make sense to lump _readers and _admins into
_security. If so, then I think this is what you would get:
{
"_readers":{
"names":["foo","bar"],
"roles":["baz"]
},
"_admins":{
"names":["jan","brian"],
"roles":["support"]
},
"other_security_stuff":{...}
}
You've also suggested adding some more granular capabilities, such as
_replicators and create-only (dropbox). Then _security would become:
{
"_readers":{
"names":["foo","bar"],
"roles":["baz"]
},
"_admins":{
"names":["jan","brian"],
"roles":["support"]
},
"_replicators":{
"names":["cron"],
"roles":["baz"],
},
"_creators":{
"names":["foo"],
"roles":["_anon"],
},
"other_security_stuff":{...}
}
Now, the top-level keys there are exactly what I called "rights", and would
be enforced in erlang by check_is_admin, check_is_reader,
check_is_replicator etc.
You can keep the data structure exactly like that. All I'm offering is that
you *could* turn the structure on its head like this:
{
"names":{
"foo":["_reader","_creator"],
"bar":["_reader"],
"jan":["_admin"],
"brian":["_admin"],
"cron":["_replicator"]
},
"roles:{
"baz":["_reader","_replicator"],
"support":["_admin"],
"_anon":["_creator"]
},
"other_security_stuff":{...}
}
I prefer this format because all the rights for one user/role are in a
single place; consequently it's easier to remove all access for a user.
The other benefit is that Futon can also display application-specific rights
without being confused by other stuff at the top level of the _security
object; and, if extra couchdb rights are added, Futon doesn't need to
change.
For example, it would be hard for Futon to display the extra 'doctors'
rights from this:
{
"_readers":{
"names":["foo","bar"],
"roles":["baz"]
},
"_admins":{
"names":["jan","brian"],
"roles":["support"]
},
"doctors":{
"names":["foo","jim"],
},
"hmac_key":"abc12345",
}
("doctors" having significance in validate_doc_update and _show/_list)
because it wouldn't know which of "doctors" and "hmac_key" should be
displayed as an ACL. But if you restructure it as
{
"names":{
"foo":["_reader","doctor"],
"bar":["_reader"],
"jan":["_admin"],
"jim":["doctor"],
"brian":["_admin"],
},
"roles:{
"baz":["_reader"],
"support":["_admin"]
},
"hmac_key":"abc12345"
}
then futon can show that jim is a doctor, and allow the doctor right to be
added to other users.
The functionality is ultimately the same though, so I'm not wedded to the
second format.
Regards,
Brian.
