incubator-couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Keno Kuhlmann <keno.kuhlm...@gmx.de>
Subject Re: Disabling doc include
Date Thu, 02 Jan 2014 13:29:44 GMT
Happy 2014 @ the list,

there is no document level (or even worse attribute level) access control mechanism implemented
in couched at this time, please correct me if I am wrong. Any type of document level access
control introduces problems with either information leaking aggregate/reduce functions or
plain wrong query results. It does not matter if implemented inside couchdb or elsewhere.
Anyhow, many applications require access control, maybe we should collect some ideas, best
practices or implement some helping functions, such as validate_read, rewrite/vhost layer,
etc.

Keno     

On 02/01/2014, at 13:27, Stanley Iriele <siriele2x3@gmail.com> wrote:

> Correct me if I'm wrong here... If every doc had some meta info with it...
> And every URL rewrite went to a show or list function...couldn't you use
> the sec object passed on the request object to get what you want?... Or
> pass in some application level user credentials... Granted that doesn't
> sound very elegant
> On Jan 2, 2014 7:22 AM, "Robert Newson" <rnewson@apache.org> wrote:
> 
>> 
>> It doesn’t achieve the same effect, though, the virtual host + url
>> rewriter is not an access control mechanism. You’re still granting
>> database-wide read permissions to the user.
>> 
>> B.
>> 
>> 
>> On 2 Jan 2014, at 09:09, Florian Westreicher Bakk.techn. <
>> stuff@meredrica.org> wrote:
>> 
>>> I put a design doc behind a desk record / virtual host, that should do
>> the trick. The user that is used by the app is read only
>>> 
>>> Robert Newson <rnewson@apache.org> wrote:
>>>> "there’s no notion of read-protection in CouchDB."
>>>> 
>>>> There’s no document level read protection, but you can certainly grant
>>>> or deny read access to users on a per database basis. That’s by design
>>>> due to the ease that information could leak out through views
>>>> (particularly reduce views). The restrictive proxy approach is brittle,
>>>> it requires that you know all the URL patterns to block and keep them
>>>> up to date when you upgrade CouchDB. It can work, it’s just not
>>>> awesome.
>>>> 
>>>> B.
>>>> 
>>>> .
>>>> 
>>>> On 1 Jan 2014, at 20:47, Jens Alfke <jens@couchbase.com> wrote:
>>>> 
>>>>> 
>>>>> On Dec 31, 2013, at 1:44 AM, meredrica <stuff@meredrica.org> wrote:
>>>>> 
>>>>>> I expose CouchDB directly to mobile clients and wanted to hide some
>>>>>> information from them.
>>>>> 
>>>>> You can’t really do that; there’s no notion of read-protection in
>>>> CouchDB.
>>>>> As a workaround you can put CouchDB behind a proxy or gateway, and
>>>> restrict the URL patterns that clients are allowed to send.
>>>>> 
>>>>> —Jens
>>>>> 
>>> 
>>> --
>>> Sent from Kaiten Mail. Please excuse my brevity.
>> 
>> 


Mime
View raw message