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