how would one replicate these write-only dropboxes? B.
On 11 July 2011 22:13, Andrew Stuart (SuperCoders) <[email protected]> wrote: > I've followed this thread but it's still somewhat unclear - > > -- is "write only" database access built in/easy to do, or must it be > enabled via some special external logic imposed at the application layer? > > as > > On 12/07/2011, at 6:39 AM, Jonathan Geddes wrote: > > 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 >>> >> >> > -- > Message protected by MailGuard: e-mail anti-virus, anti-spam and content > filtering.http://www.mailguard.com.au/mg > Click here to report this message as spam: > https://login.mailguard.com.au/report/1CGUOUsAWN/2BVxdPfDhfeJK4SLOnz0gl/1 >
