On 26 Oct 2010, at 17:25, 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.
http://s.apache.org/couchdb-per-doc-auth Cheers Jan --
