couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robert Newson <robert.new...@gmail.com>
Subject Re: no 'writers' section in _security killing me
Date Mon, 18 Jul 2011 16:03:45 GMT
easier to test for a role instead and just users to that role.

On 18 July 2011 16:24, Mehdi El Fadil <mehdi.elfadil@mango-is.com> wrote:
> 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
View raw message