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 23:14:15 GMT
Yes I would like to be able to build "pure" 2 tier CouchApps, and  
would like to avoid the extra logic.

as




On 12/07/2011, at 9:10 AM, Jonathan Geddes wrote:

I totally agree that this should be built in. It doesn't seem like it  
would
be a very difficult change to implement.

--Jonathan

On Mon, Jul 11, 2011 at 5:02 PM, Andrew Stuart (SuperCoders) <
andrew.stuart@supercoders.com.au> wrote:

> Okay I understand now I think - essentially "write only" access  
> control for
> a given user is not built-in.  Seems like a good thing to be part of  
> the
> basic security model - does anyone else agree, or is the general  
> consensus
> that this is not something that should be part of the access control  
> model?
>
> as
>
>
>
>
>
> On 12/07/2011, at 8:48 AM, Jonathan Geddes 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 <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<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.**mailgua**rd.com.au/mg<http://mailguard.com.au/mg 
>>> >
>>> <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<https://login.mailguard.com.au/report/1CGUOUsAWN/2BVxdPfDhfeJK4SLOnz0gl/1

>>> >
>>>>
>>>
>>> --
>>>
>> Message  protected by MailGuard: e-mail anti-virus, anti-spam and  
>> content
>> filtering.http://www.**mailgua**rd.com.au/mg <http://mailguard.com.au/mg 
>> >
>> <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<https://login.mailguard.com.au/report/1CGW2fhE4N/5SE2wTOEjJss04ObshZ4q9/1

>> >
>>>
>>
>>

Mime
View raw message