couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jan Lehnardt <...@apache.org>
Subject Re: Introducing Bram Neijt
Date Thu, 28 Oct 2010 14:29:37 GMT

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 <jan@apache.org> 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 <benjamin@couchone.com> 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 !
> 


Mime
View raw message