Andrew, There's nothing built in, but there are apparently a couple of possible workarounds:
1. Use the '2.1 layer architecture': have something (like nodejs) listening for changes on the public database that moves the data to a private database and removes it from the public database. 2. Use the built-in rewriter to limit access to a given database to POST/PUT (don't allow GET through) --Jonathan On Mon, Jul 11, 2011 at 4:27 PM, Andrew Stuart (SuperCoders) < [email protected]> wrote: > Sorry I phrased that badly. > > Back in the days of Lotus Notes it was possible to have users who were able > to write into, but not read from a database. Is similar functionality built > in to CouchDB or must it be enabled by external logic? > > as > > > > > On 12/07/2011, at 7:48 AM, Robert Newson wrote: > > how would one replicate these write-only dropboxes? > > B. > > On 11 July 2011 22:13, Andrew Stuart (SuperCoders) > <andrew.stuart@supercoders.**com.au <[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<http://www.mailguard.com.au/mg> >> Click here to report this message as spam: >> https://login.mailguard.com.**au/report/1CGUOUsAWN/** >> 2BVxdPfDhfeJK4SLOnz0gl/1<https://login.mailguard.com.au/report/1CGUOUsAWN/2BVxdPfDhfeJK4SLOnz0gl/1> >> >> -- > Message protected by MailGuard: e-mail anti-virus, anti-spam and content > filtering.http://www.**mailguard.com.au/mg<http://www.mailguard.com.au/mg> > Click here to report this message as spam: > https://login.mailguard.com.**au/report/1CGW2fhE4N/** > 5SE2wTOEjJss04ObshZ4q9/1<https://login.mailguard.com.au/report/1CGW2fhE4N/5SE2wTOEjJss04ObshZ4q9/1> >
