On Mon, Jul 11, 2011 at 12:17 PM, Jonathan Geddes <[email protected]> wrote: >> Fortunately, users with write access are not admins. They may not >> modify design documents. All of their changes are subject to design >> documents' validate_doc_update() function. > > I would be *overjoyed* to hear that you are right and the documentation at > [0] is wrong: >> database admins - Defined per database. They have all the privileges > readers have plus the privileges: write (and edit) design documents, > add/remove database admins and readers, set the database revisions limit > > (/somedb/_revs_limit API) and execute temporary views against the database > (/somedb/_temp_view API). They can not create a database and neither delete > a database.
D'oh, Marcello posted a pithy and timely answer while I had lunch. I'll send anyway. The typical setup is: * 1 server admin * 0 or more database admins (name or roles in _security.admins) * An admin deploys a design document * Several normal users (name or roles in _security.readers but *not* admins) "readers" is a misnomer. It really means "members." Read access is database-wide, write access is at the pleasure of validate_doc_update(). To that end, Chris changed CouchDB so that future releases will use the "members" field. He committed his change last Thanksgiving weekend. Thanks, Chris! > I'm gonna set up a little experiment in the morning (when I can think > clearly) to find out for myself. The _revs_limit PI and temporary views are > scary too. I strongly encourage an experiment. 15 or 20 minutes of poking around will make things very clear. Cloudant has a brilliant UI to impose more intuitive and traditional security policies for exactly this reason. >> I call it a 2.5-layer architecture >> because there is no middleware, but it still requires a third >> component, to watch over things. The drop box would be amazing; >> however I am still happy with my architecture because bugs or crashes >> in the third component are not so devastating to the user experience. > > The great thing about this architecture is that you can easily have CouchDB > monitor the third party stuff and keep it running with external OS processes > [1]. I like the term '2.5-layer' :D. Is it too late to change the name to "2.1-layer"? * Hints that the extra step is not going to break your back * Kind of like 5.1 surround sound > By the way, why hasn't this been implimented before? It seems strange to me. > Is there something inherent in the architecture of CouchDB that makes this > difficult? I think it is a matter of time. The people in a position to implement it have not felt quite enough pressure. /me whistles innocently. -- Iris Couch
