On Wed, Aug 17, 2011 at 9:18 PM, Adam Kocoloski <kocol...@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