One more possible solution: Could I use the rewriter to make sure that that only POST and PUT go through to a given database? How secure is this approach?
--Jonathan On Mon, Jul 11, 2011 at 8:45 AM, Jonathan Geddes <[email protected]>wrote: > Thanks for the responses, everyone. > > So I've been using CouchDB for about a year, but I'm only now getting into > the "2.1 Layer Architecture" (cutting back from a 3+ layer). > > Apparently I've been using readers and admins wrong all along. I thought > that only admins could write documents. After all, why would I think that > 'readers' could write? I've been a victim of the misnomer! > > I still think that the dropbox feature would be immensely useful, and I > still might take a whack at implementing it. > > Thanks for the clarification, > > --Jonathan > > > On Mon, Jul 11, 2011 at 1:17 AM, Jason Smith <[email protected]> wrote: > >> 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 >> > >
