On Thu, Feb 11, 2010 at 4:20 AM, Brian Candler <b.cand...@pobox.com> wrote:
>> 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":{...}
> }
>
>
To be clear, I'm not suggesting this at all.
It'd be more like (pardon my earlier accidental _underscores):
{
"readers":{
"names":["foo","bar"],
"roles":["baz", "_replicator", "doctor"]
},
"admins":{
"names":["jan","brian"],
"roles":["support", (_admin is an implied member)]
},
"other_security_stuff":{...}
}
_replicator, etc wouldn't go in as top level keys with special
meaning. They'd be just another role like doctor or foo. I actually
can't think of a time you'd put _replicator into the ACLs. It'd be
more likely something checked by the validation function. (Eg only
allow docs to be written if doc.author == userCtx.name, unless we are
replicating and the replication was triggered with both _admin and
_replicator roles.) The more I think about it the more of a bad idea I
think a _replicator role could potentially be.
As far as drop box, I think it'd just be a boolean flag ("allow anyone
to write to this database even if they aren't in the readers list")
which should be easy to add in the future without changing any of the
existing stuff.
There's no need for a _creators list as that can be implemented in the
validation function.
> 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.
Something like check_is_replicator can be written in javascript and be
part of the validation function.
>
> 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.
>
--
Chris Anderson
http://jchrisa.net
http://couch.io
