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 22:27:26 GMT
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> 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
> Click here to report this message as spam:
> 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
Click here to report this message as spam:
https://login.mailguard.com.au/report/1CGW2fhE4N/5SE2wTOEjJss04ObshZ4q9/1

Mime
View raw message