Mailing-List: contact user-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@couchdb.apache.org
Received-SPF: pass (athena.apache.org: domain of maxosmail@gmail.com
 designates 209.85.212.52 as permitted sender)
MIME-Version: 1.0
Sender: maxosmail@gmail.com
In-Reply-To: 
 <CAFnw-01taB0wifP3ue3Sr-xnJV6xeCraU+gnHO53yd3ovTMa2Q@mail.gmail.com>
References: 
 <CAFnw-00a2hux2T0ZP=wKGHq++je4AmXTjZQxKWTXpvezOtvZeg@mail.gmail.com>
 <CAN-3CBLAY1-UzbRsaR_aaJNT+uh8pPjOT_WoL83ex13wvU-Q4w@mail.gmail.com>
 <CAFnw-03MZdTm1fOcjGepZQCLq5yLiDooKr92SR2frg9nf1YJYQ@mail.gmail.com>
 <CAN-3CBLGPYC+zJSVzUUEVTn7XDSrm6Ce2yUTJkUqDBy3JtkKpQ@mail.gmail.com>
 <CAFnw-03xzfT63iHEfdv=zvbA60i6atWAHT4BHbzxNFsXGk1EWQ@mail.gmail.com>
 <CAFnw-01taB0wifP3ue3Sr-xnJV6xeCraU+gnHO53yd3ovTMa2Q@mail.gmail.com>
From: Max Ogden <max@maxogden.com>
Date: Mon, 11 Jul 2011 14:06:11 -0700
Message-ID: 
 <CAONf+LSkqSHSrO+tJmD2nKJ20sBu3cqNSHvT4v9cxEZRwSw0RA@mail.gmail.com>
Subject: Re: no 'writers' section in _security killing me
To: user@couchdb.apache.org
Content-Type: multipart/alternative; boundary=20cf307d00f0b5b3dd04a7d18e38

--20cf307d00f0b5b3dd04a7d18e38
Content-Type: text/plain; charset=UTF-8

i just wrote an html5 drag and drop uploader for couch, feel free to use it
for your dropbox clone :) http://open211.org/#upload

On Mon, Jul 11, 2011 at 1:39 PM, Jonathan Geddes
<geddes.jonathan@gmail.com>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
> <geddes.jonathan@gmail.com>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 <jhs@iriscouch.com> wrote:
> >
> >> On Mon, Jul 11, 2011 at 12:17 PM, Jonathan Geddes
> >> <geddes.jonathan@gmail.com> 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
> >>
> >
> >
>

--20cf307d00f0b5b3dd04a7d18e38--