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