Hi, What about storing the list of writers inside the validation function, and not having these users in the security object of the database?
Technically, is there a problem in this approach for a write-only database? The validation function would have to be updated each time a writer needs to be added. Mehdi. On Tue, Jul 12, 2011 at 12:48 AM, Jonathan Geddes <[email protected] > wrote: > 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> > > >
