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