Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@couchdb.apache.org
Received-SPF: pass (athena.apache.org: domain of samuelgoto@gmail.com
 designates 209.85.216.180 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=kzsZnpmIoiCR+gi/fHORWWQeA+GhwWbVbF39steCQ60dutVe9686xGD6bLPFalJxlq
         FP98bLdFCT58r1GFTyTAQounOzQVxavuxAgiGFzbYZ3QUZQJScD0ngwmMlaxSZ4VRI7/
         r8cKheID60pI5U7uylZC+cFeEy8ktv7iAk1Es=
MIME-Version: 1.0
In-Reply-To: <750A58D2-3F68-4865-8A37-9C36EB5C27C0@apache.org>
References: <AANLkTik_Uq5qJJNU9752Gq99DnANw1YHhDp1Ccjf8_b5@mail.gmail.com>
	<C18C1BE1-8093-47A8-8634-3CB2B2D4EC14@apache.org>
	<C4B01815-5A28-4E5F-975D-70344B7570EC@apache.org>
	<4CC6F637.3010007@couchone.com>
	<AANLkTik-A1yNVA7Rj49Lca7=_mth7_fRV8w2oBY+_9vv@mail.gmail.com>
	<A99A2BB9-29AB-4F06-8824-6A8543113EA9@apache.org>
	<AANLkTikAFFiObZGh3uOEFFP4Wq9Np0knrREbtgrSheyS@mail.gmail.com>
	<0A04DCBD-8CC5-488A-873E-2FCE52069377@googlemail.com>
	<750A58D2-3F68-4865-8A37-9C36EB5C27C0@apache.org>
Date: Thu, 28 Oct 2010 08:43:53 -0700
Message-ID: <AANLkTi=MtJJPD0ybKnS_1KsOONffzmwah_Wq7wns+yVh@mail.gmail.com>
Subject: Re: Introducing Bram Neijt
From: sgoto <samuelgoto@gmail.com>
To: dev@couchdb.apache.org
Content-Type: multipart/alternative; boundary=20cf3005129290237c0493af352b

--20cf3005129290237c0493af352b
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

argh sorry, wrong link :) i hope this one works now :)

https://docs.google.com/document/pub?id=3D1NWZ9xhsQvUL24IDa4erYcEZwkoNH6m13=
fizn8_og0gY

On Thu, Oct 28, 2010 at 7:29 AM, Jan Lehnardt <jan@apache.org> wrote:

>
> On 28 Oct 2010, at 14:38, Sebastian Cohnen wrote:
>
> > nice example, the document is not public ;)
>
> haha, I thought that was the joke :D
>
> Cheers
> Jan
> --
>
> >
> > On 27.10.2010, at 18:08, sgoto wrote:
> >
> >> i've put together a document on how i am handling per document
> authorization
> >> for my couchdb projects. it might be useful.
> >>
> >>
> https://docs.google.com/document/edit?id=3D1NWZ9xhsQvUL24IDa4erYcEZwkoNH6=
m13fizn8_og0gY&hl=3Den&pli=3D1#
> >>
> >> On Tue, Oct 26, 2010 at 3:12 PM, Jan Lehnardt <jan@apache.org> wrote:
> >>
> >>> Thanks Dave, much appreciated.
> >>>
> >>> If anybody else wants to beat him to it=85it=92s a public wiki :)
> >>>
> >>> Cheers
> >>> Jan
> >>> --
> >>>
> >>> On 26 Oct 2010, at 21:56, Dave Cottlehuber wrote:
> >>>
> >>>> re wiki -> I will add this in next few days.
> >>>>
> >>>> On 27 October 2010 04:39, Benjamin Young <benjamin@couchone.com>
> wrote:
> >>>>> On 10/26/2010 11:25 AM, Adam Kocoloski wrote:
> >>>>>>
> >>>>>> On Oct 26, 2010, at 10:48 AM, Jan Lehnardt wrote:
> >>>>>>
> >>>>>>> Hi Bram,
> >>>>>>>
> >>>>>>> On 26 Oct 2010, at 11:51, Bram Neijt wrote:
> >>>>>>>
> >>>>>>>> I'm a developer at Xebia and I've been granted about 5 hours a
> week
> >>> to
> >>>>>>>> spend on implementing any open source project problem I would li=
ke
> to
> >>>>>>>> see fixed.
> >>>>>>>
> >>>>>>> This major awesome! :)
> >>>>>>>
> >>>>>>>
> >>>>>>>> I've chosen to have a go at per document authorization for
> couchdb.
> >>>>>>>
> >>>>>>> Uh-oh :) =97 See below.
> >>>>>>>
> >>>>>>>
> >>>>>>>> As I'm weeding through the archives, I would love to hear about
> the
> >>>>>>>> current approaches, who is involved, what is planned and what ma=
y
> be
> >>>>>>>> considered an acceptable solution.
> >>>>>>>
> >>>>>>> To get started more generally, it might make sense to check out
> >>>>>>> our list of issues sorted by how hard they are to solve:
> >>>>>>>
> >>>>>>> http://s.apache.org/couchdb-easy-issues
> >>>>>>> http://s.apache.org/couchdb-medium-issues
> >>>>>>> http://s.apache.org/couchdb-hard-issues
> >>>>>>>
> >>>>>>> (Thanks again for Paul Davis to produce these lists)
> >>>>>>>
> >>>>>>> --
> >>>>>>>
> >>>>>>> As for per-doc auth: It is very hard to get right and probably
> >>>>>>> against the nature of CouchDB. I'm not saying we shouldn't try
> >>>>>>> to solve it, but we need to be aware of the impact.
> >>>>>>>
> >>>>>>> I remember Damien saying that Notes did get per-doc auth, but
> >>>>>>> it wasn't a good solution and it sucked ever since. I don't
> >>>>>>> think anybody here wants that :)
> >>>>>>>
> >>>>>>> The biggest problem here are views, the reduced kind.
> >>>>>>>
> >>>>>>> From the reduce value, CouchDB can't deduce what documents were
> >>>>>>> used to create the value.
> >>>>>>>
> >>>>>>> Imagine three docs
> >>>>>>>
> >>>>>>> {"name": "a", "amount": 3}
> >>>>>>> {"name": "b", "amount": 5}
> >>>>>>> {"name": "c", "amount": 7}
> >>>>>>>
> >>>>>>> A map function:
> >>>>>>>
> >>>>>>> function(doc) {
> >>>>>>> emit(doc.name, doc.amount);
> >>>>>>> }
> >>>>>>>
> >>>>>>> A reduce function:
> >>>>>>>
> >>>>>>> function(keys, values) {
> >>>>>>> return sum(values);
> >>>>>>> }
> >>>>>>>
> >>>>>>> Now the reduced result for this view is 15. Now say you don't
> >>>>>>> have access to read the document with `"name": "b"`. Should you
> >>>>>>> be able to access the view? If yes, what result should you see?
> >>>>>>> 15? 10?
> >>>>>>>
> >>>>>>> If you get 15, then the view is leaking information that you
> >>>>>>> are not supposed to see (IIRC that's how Notes works).
> >>>>>>>
> >>>>>>> If you are supposed to get 10, the underlying data structure
> >>>>>>> would have to compute a view for each user based on his/her
> >>>>>>> authorization settings. And invalidate the view every time
> >>>>>>> these are changed.
> >>>>>>>
> >>>>>>> To make a rather straightforward implementation of that, J Chris
> >>>>>>> proposed the idea of prefixing views with the username and only
> >>>>>>> allowing reads with a prefix that is the authenticated username.
> >>>>>>>
> >>>>>>> While that is conceptually rather easy, you are basically creatin=
g
> >>>>>>> a view for each user. This may work for small amounts of data,
> >>>>>>> but not large, and many users.
> >>>>>>>
> >>>>>>>
> >>>>>>> Again, I'm not saying, you shouldn't attempt to solve this,
> >>>>>>> because that'd be =FCber-rad, but there be dragons :)
> >>>>>>>
> >>>>>>> Either way, you may want to jump in with the easier open issues
> >>>>>>> to get a feeling for the codebase and the procedure of submitting
> >>>>>>> patches and all that.
> >>>>>>>
> >>>>>>> Glad to have you on board!
> >>>>>>>
> >>>>>>> Cheers
> >>>>>>> Jan
> >>>>>>> --
> >>>>>>
> >>>>>> Well said Jan, and welcome Bram!  This explanation needs to not ge=
t
> >>> lost
> >>>>>> in the archives.
> >>>>>
> >>>>> +1 for getting this on the wiki, a blog, or somewhere that it's
> >>> findable.
> >>>>> It's sort of become "lore" that per-document permissions aren't
> >>> currently
> >>>>> doable in CouchDB, but this is the clearest explanation I've heard,
> and
> >>>>> worth repeating in a more public venue. :)
> >>>>>
> >>>>> Thanks, Jan,
> >>>>> Benjamin
> >>>>>>
> >>>>>> Adam
> >>>>>>
> >>>>>
> >>>>>
> >>>
> >>>
> >>
> >>
> >> --
> >> f u cn rd ths u cn b a gd prgmr !
> >
>
>


--=20
f u cn rd ths u cn b a gd prgmr !

--20cf3005129290237c0493af352b--