Return-Path: X-Original-To: apmail-couchdb-user-archive@www.apache.org Delivered-To: apmail-couchdb-user-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 41D957EE5 for ; Mon, 18 Jul 2011 16:04:18 +0000 (UTC) Received: (qmail 49755 invoked by uid 500); 18 Jul 2011 16:04:16 -0000 Delivered-To: apmail-couchdb-user-archive@couchdb.apache.org Received: (qmail 49689 invoked by uid 500); 18 Jul 2011 16:04:15 -0000 Mailing-List: contact user-help@couchdb.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: user@couchdb.apache.org Delivered-To: mailing list user@couchdb.apache.org Received: (qmail 49681 invoked by uid 99); 18 Jul 2011 16:04:15 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 18 Jul 2011 16:04:15 +0000 X-ASF-Spam-Status: No, hits=1.8 required=5.0 tests=FREEMAIL_FROM,FREEMAIL_REPLY,RCVD_IN_DNSWL_LOW,SPF_PASS,T_TO_NO_BRKTS_FREEMAIL X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of robert.newson@gmail.com designates 209.85.214.180 as permitted sender) Received: from [209.85.214.180] (HELO mail-iw0-f180.google.com) (209.85.214.180) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 18 Jul 2011 16:04:07 +0000 Received: by iwn9 with SMTP id 9so5925603iwn.11 for ; Mon, 18 Jul 2011 09:03:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; bh=xa7/oDFAwewov8OU87FOgITUImoNDbdsh1knfOOGN9o=; b=vJknFGpvuwH3r8bIRM7RJDLyDq194hNdYaYe1dWP7Q3VHGyQI5XmXAlU1WVN1p7q3+ kd2eoFwQ9Ds/rzkRYjJLUC+orW+iKxaokOyMLfHQyvDO7en4KGx+31Y/pU9VT2ForHkc RHPHfIn5V29L9HEEKoOYQxIretsf4p1w/2NpI= MIME-Version: 1.0 Received: by 10.231.63.198 with SMTP id c6mr5886757ibi.159.1311005026439; Mon, 18 Jul 2011 09:03:46 -0700 (PDT) Received: by 10.231.145.67 with HTTP; Mon, 18 Jul 2011 09:03:45 -0700 (PDT) In-Reply-To: References: <27D42026-5335-4A62-B47C-A7DF2BA28EE9@supercoders.com.au> <0CE6808D-D545-43CD-85D4-72CD8832F32E@supercoders.com.au> Date: Mon, 18 Jul 2011 17:03:45 +0100 Message-ID: Subject: Re: no 'writers' section in _security killing me From: Robert Newson To: user@couchdb.apache.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Virus-Checked: Checked by ClamAV on apache.org easier to test for a role instead and just users to that role. On 18 July 2011 16:24, Mehdi El Fadil wrote: > Hi, > > What about storing the list of writers inside the validation function, an= d > not having these users in the security object of the database? > > Technically, is there a problem in this approach for a write-only databas= e? > > 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 > 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) listen= ing >> 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) < >> andrew.stuart@supercoders.com.au> 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. =A0Is similar functionali= ty >> 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) >> > = > >> > 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 tha= t >> >> 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 >> >> **wrote: >> >> >> >> =A0Thanks for the responses, everyone. >> >>> >> >>> So I've been using CouchDB for about a year, but I'm only now gettin= g >> >>> 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, an= d 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 >> wrote: >> >>> >> >>> =A0On Mon, Jul 11, 2011 at 12:17 PM, Jonathan Geddes >> >>>> wrote: >> >>>> >> >>>>> >> >>>>>> Fortunately, users with write access are not admins. They may not >> >>>>>> modify design documents. All of their changes are subject to desi= gn >> >>>>>> 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 privile= ges >> >>>>>> >> >>>>> >> >>>>> readers have plus the privileges: write (and edit) design document= s, >> >>>>> 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 neith= er >> >>>>> >> >>>> >> >>>> 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! >> >>>> >> >>>> =A0I'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 arou= nd >> >>>> will make things very clear. >> >>>> >> >>>> Cloudant has a brilliant UI to impose more intuitive and traditiona= l >> >>>> security policies for exactly this reason. >> >>>> >> >>>> =A0I 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 hav= e >> >>>>> >> >>>> >> >>>> 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 >> >>>> >> >>>> =A0By the way, why hasn't this been implimented before? It seems st= range >> >>>>> to >> >>>>> >> >>>> >> >>>> me. >> >>>> >> >>>>> >> >>>>> Is there something inherent in the architecture of CouchDB that ma= kes >> >>>>> >> >>>> >> >>>> this >> >>>> >> >>>>> >> >>>>> difficult? >> >>>>> >> >>>> >> >>>> I think it is a matter of time. The people in a position to impleme= nt >> >>>> it have not felt quite enough pressure. >> >>>> >> >>>> /me whistles innocently. >> >>>> >> >>>> -- >> >>>> Iris Couch >> >>>> >> >>>> >> >>> >> >>> =A0-- >> >> Message =A0protected 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> >> >> >> >> =A0-- >> > Message =A0protected by MailGuard: e-mail anti-virus, anti-spam and co= ntent >> > 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> >> > >> >