Mailing-List: contact user-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@couchdb.apache.org
Received-SPF: pass (nike.apache.org: domain of keno.kuhlmann@gmx.de designates
 212.227.17.20 as permitted sender)
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1816\))
Subject: Re: Disabling doc include
From: Keno Kuhlmann <keno.kuhlmann@gmx.de>
In-Reply-To: 
 <CAPNuaCjcJfFVYn2anYkJ03mU0d=4VfgEEj-s3Wp=udhgJF_92w@mail.gmail.com>
Date: Thu, 2 Jan 2014 14:29:44 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <6544C8A0-40AA-4650-9CCF-1957CB6111DA@gmx.de>
References: <52C28C30.7010809@meredrica.org>
 <CAHdjipKDnJL=FMsB9LFzLR2oLTLV6n-+5rc_G06+XX_Y1J-m1w@mail.gmail.com>
 <52C291F9.80708@meredrica.org>
 <ACE57B78-1CE5-4D4F-AAB5-032415799F52@couchbase.com>
 <0C582CB4-CAA4-4BB4-A4EB-9529E177F0C9@apache.org>
 <43fe89b9-4cd4-4765-b406-33b7c3f7f66b@email.android.com>
 <10410DFE-478D-49EC-A022-01B89E498182@apache.org>
 <CAPNuaCjcJfFVYn2anYkJ03mU0d=4VfgEEj-s3Wp=udhgJF_92w@mail.gmail.com>
To: user@couchdb.apache.org

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    =20

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:
>=20
>>=20
>> It doesn=92t achieve the same effect, though, the virtual host + url
>> rewriter is not an access control mechanism. You=92re still granting
>> database-wide read permissions to the user.
>>=20
>> B.
>>=20
>>=20
>> On 2 Jan 2014, at 09:09, Florian Westreicher Bakk.techn. <
>> stuff@meredrica.org> wrote:
>>=20
>>> 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
>>>=20
>>> Robert Newson <rnewson@apache.org> wrote:
>>>> "there=92s no notion of read-protection in CouchDB."
>>>>=20
>>>> There=92s no document level read protection, but you can certainly =
grant
>>>> or deny read access to users on a per database basis. That=92s 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=92s just not
>>>> awesome.
>>>>=20
>>>> B.
>>>>=20
>>>> .
>>>>=20
>>>> On 1 Jan 2014, at 20:47, Jens Alfke <jens@couchbase.com> wrote:
>>>>=20
>>>>>=20
>>>>> On Dec 31, 2013, at 1:44 AM, meredrica <stuff@meredrica.org> =
wrote:
>>>>>=20
>>>>>> I expose CouchDB directly to mobile clients and wanted to hide =
some
>>>>>> information from them.
>>>>>=20
>>>>> You can=92t really do that; there=92s 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.
>>>>>=20
>>>>> =97Jens
>>>>>=20
>>>=20
>>> --
>>> Sent from Kaiten Mail. Please excuse my brevity.
>>=20
>>=20