argh sorry, wrong link :) i hope this one works now :) https://docs.google.com/document/pub?id=1NWZ9xhsQvUL24IDa4erYcEZwkoNH6m13fizn8_og0gY
On Thu, Oct 28, 2010 at 7:29 AM, Jan Lehnardt <[email protected]> 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=1NWZ9xhsQvUL24IDa4erYcEZwkoNH6m13fizn8_og0gY&hl=en&pli=1# > >> > >> On Tue, Oct 26, 2010 at 3:12 PM, Jan Lehnardt <[email protected]> wrote: > >> > >>> Thanks Dave, much appreciated. > >>> > >>> If anybody else wants to beat him to it…it’s 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 <[email protected]> > 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 like > to > >>>>>>>> see fixed. > >>>>>>> > >>>>>>> This major awesome! :) > >>>>>>> > >>>>>>> > >>>>>>>> I've chosen to have a go at per document authorization for > couchdb. > >>>>>>> > >>>>>>> Uh-oh :) — 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 may > 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 creating > >>>>>>> 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 über-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 get > >>> 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 ! > > > > -- f u cn rd ths u cn b a gd prgmr !
