incubator-couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jonathan Geddes <geddes.jonat...@gmail.com>
Subject Re: no 'writers' section in _security killing me
Date Mon, 11 Jul 2011 14:45:08 GMT
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
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message