couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mehdi El Fadil <mehdi.elfa...@mango-is.com>
Subject Re: no 'writers' section in _security killing me
Date Mon, 18 Jul 2011 15:24:27 GMT
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 <geddes.jonathan@gmail.com
> 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) <
> 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.  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>>
> > 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
> >> <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
> >>>>
> >>>>
> >>>
> >>>  --
> >> 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>
> >
>

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