incubator-couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andrew Stuart (SuperCoders)" <andrew.stu...@supercoders.com.au>
Subject Re: no 'writers' section in _security killing me
Date Mon, 11 Jul 2011 21:13:22 GMT
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
Click here to report this message as spam:
https://login.mailguard.com.au/report/1CGUOUsAWN/2BVxdPfDhfeJK4SLOnz0gl/1

Mime
View raw message