Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@couchdb.apache.org
Received-SPF: pass (nike.apache.org: domain of bchesneau@gmail.com designates
 209.85.160.56 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :content-type;
        b=vbxhFDBbSGGVV8jV3bS2OZuVqZb7gHqeN/s9opfbVn7VQEygnEHm2P5zqHiblIbi2D
         ZICnMPuSxT52+CLxmHU+LEmK+mVX3UlxqyBjmBpV62Ab7EcrJ+OpMXDE1l3KeqRKOEjL
         cpEyxjQwvdNwtKJDy8MoW02PbRCrnxSTzpGXs=
MIME-Version: 1.0
In-Reply-To: <e282921e0911011059y1befba46sd97b7999fbce8c5c@mail.gmail.com>
References: <b7cd8ed10911010333h3e68c354sa0c38deb75f0bf81@mail.gmail.com>
	 <e282921e0911011059y1befba46sd97b7999fbce8c5c@mail.gmail.com>
Date: Sun, 1 Nov 2009 22:25:15 +0100
Message-ID: <b7cd8ed10911011325t36a3b8e7i843bfc39b640f009@mail.gmail.com>
Subject: Re: auth per db - thoughts and question
From: Benoit Chesneau <bchesneau@gmail.com>
To: dev@couchdb.apache.org
Content-Type: text/plain; charset=ISO-8859-1

On Sun, Nov 1, 2009 at 7:59 PM, Chris Anderson <jchris@apache.org> wrote:
> On Sun, Nov 1, 2009 at 3:33 AM, Benoit Chesneau <bchesneau@gmail.com> wrote:
>> Hi,
>>
>> I'm working on a authentification per db for couchdb. I failed to find
>> a right system actually and trashed my code this morning. Suggested by
>> Jan, I post here my thoughts about it. Main goals are :
>>
>> - Set permission read or write for users on a db
>
> I think the goal of getting this level of permissions is enough for
> one patch. Throwing replication into the mix adds a whole level of
> complexity.
>
> Imagine the user credentials are stored in the "users" db on node A,
> and user Bob own db "foo" on node A, while user Alice has read-only
> access to "foo" on node A.
>
> If Alice replicates "foo" to her laptop, Bob doesn't own it there. She
> can now make all the edits she wants. However, she won't be able to
> replicate them to Bob's "foo", because she can't write there. She can
> make a "foo-alice" db and give Bob read access, and he can merge from
> there to his "foo" db. A lot like git.

I'm agree with this process, this is simple. But still git contain
user "signature" with email and sometimes also the gpg signature so
you can continue to track access/merge/branching whatever.

>
> ==
>
> I think if we ignore replication when thinking about node A's
> configuration, we'll be much much more successful. Leaving replication
> out of the story frees admins to use it how they see fit.
>
> Imagine that node A is at the office, and they hire 500 people to a
> new location, so now they have node A and node B. People in the new
> office keep their databases on node B. IT wants to share credentials
> and access controls across the two nodes, so they just setup
> continuous replication on the users db - and done.
>
> Chris
>
>
This schema works only in a trusted environment, doesn't it ?. I would
like to be able to only share users / db rather than a whole db. A
pub/private system would allow it, and also would allow later to have
a way to follow documents/users imo. Anyway right step by step, and
your schema above allow already the replication if one user allow read
access  exceot maybe for ddocs maybe.


Anyway that may be a feature for 0.11 ? I could work on it quietly.
For now I found an alternative to that for my service.

- benoit