couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jason Smith <...@iriscouch.com>
Subject Re: The _security object should be versioned
Date Wed, 17 Aug 2011 14:35:56 GMT
On Wed, Aug 17, 2011 at 9:18 PM, Adam Kocoloski <kocolosk@apache.org> wrote:
> I believe the _security object should be versioned in order to ease synchronization of
the object between databases.  This proposal is motivated (unsurprisingly) by BigCouch, which
typically stores multiple copies of each database in a multi-master configuration.  When
the _security object is written in BigCouch the update is issued to all available shards.
 We run into problems if an update is issued while some shards are unavailable, because we
don't know how to synchronize the divergent copies once all the shards are back online.
>
> In my head I see us representing the _security object using a #full_doc_info, just as
we would a document.  Unlike documents the _security object (or a pointer to it) would still
be written in the header of the database for fast access during request processing.
>
> I haven't quite decided what I think the API should look like, e.g. whether the full
document API (including attachments?) should be supported.  Regards,

In the spirit of re-using existing working components:

How do you feel about migrating to a blessed _local/security document?
Maybe its latest version could be cached in the header for speed?

Pros:

* Couch gets (conceptually) simpler rather than more complex
* It's versioned, you get full doc semantics
* It doesn't replicate, but 3rd-party tools can pseudo-replicate it as needed
* Design documents can enforce policies: if(doc._id == _local/security
&& doc.members.length == 0) throw {forbidden:"This database may never
be public"}

Eagerly awaiting a list of cons :)

Since the _security object is conveniently glued to databases but not
replicated, I have been tempted to overload it to store per-database
security settings. There is the CORS discussion, but even simple
stuff:

{ "admins": {"names":[...], "roles":[...]}
, "members": {"names":[...], "roles":[...]}
, "read_only": true
, "create_only": true
, "delete_only": true
, "changes_only_allowed_on":"thursday"
}

// validate_doc_update
function(newDoc, oldDoc, userCtx, secObj) {
    // read_only, create_only, delete_only obviously aren't true at the
    // same time, just making a concise example.

    // Read-only example
    if(secObj.read_only)
      throw {forbidden: "This database is read-only"};

    // Create-only example
    if(oldDoc && secObj.create_only)
      throw {forbidden: "This database is create-only"};

    // Delete-only example
    if(!newDoc._deleted && secObj.delete_only)
      throw {forbidden: "This database is delete-only"};

    // Changes only allowed on Thursday left as an exercise.
}

However I have not done that because I'm not sure if it is "with the
grain" in CouchDB. Maybe these are best swallowed up into the ddoc
itself. (But then when I replicate, now I have to quickly update that
ddoc for that database's security environment.)

-- 
Iris Couch

Mime
View raw message