On Wed, Aug 17, 2011 at 9:18 PM, Adam Kocoloski <[email protected]> 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
