I totally agree that this should be built in. It doesn't seem like it would be a very difficult change to implement.
--Jonathan On Mon, Jul 11, 2011 at 5:02 PM, Andrew Stuart (SuperCoders) < [email protected]> wrote: > Okay I understand now I think - essentially "write only" access control for > a given user is not built-in. Seems like a good thing to be part of the > basic security model - does anyone else agree, or is the general consensus > that this is not something that should be part of the access control model? > > as > > > > > > On 12/07/2011, at 8:48 AM, Jonathan Geddes 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].**au <[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 >> <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.**mailgua**rd.com.au/mg<http://mailguard.com.au/mg> >>> <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<https://login.mailguard.com.au/report/1CGUOUsAWN/2BVxdPfDhfeJK4SLOnz0gl/1> >>> > >>> >>> -- >>> >> Message protected by MailGuard: e-mail anti-virus, anti-spam and content >> filtering.http://www.**mailgua**rd.com.au/mg <http://mailguard.com.au/mg> >> <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<https://login.mailguard.com.au/report/1CGW2fhE4N/5SE2wTOEjJss04ObshZ4q9/1> >> > >> >>
