You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@couchdb.apache.org by Bram Neijt <bn...@gmail.com> on 2010/10/26 11:51:37 UTC
Introducing Bram Neijt
Hi everybody,
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.
I've chosen to have a go at per document authorization for couchdb.
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.
Looking forward to making a contribution,
Bram
Re: Introducing Bram Neijt
Posted by Brian Mitchell <bi...@gmail.com>.
On Tue, Oct 26, 2010 at 10:48, Jan Lehnardt <ja...@apache.org> wrote:
> 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 :)
I'm currently looking for a clear explanation of what Notes did online
but I just hit lots of manuals with very little help. If someone has a
pointer here, I'd love to look into this.
> The biggest problem here are views, the reduced kind.
I kind of feel like views output something different enough from the
original document
that you should be able to tag each "document" that the view outputs
in a similar manner. It'd also be interesting to consider view
specific security defaults in a similar way to database security.
That still means that maps with a reduce on it would not compute based
on roles... but that the output would have to aggregate things in a
way which would produce the desired result. This basically means, it'd
be up to the view writer... not keeping them separate. In most of
those cases, I see separate databases as a better solution than clever
view partitioning per user.
Other questions:
Can the document security attributes add or only subtract from the
database security defaults?
Will we need a special category at the database level to note the
types of users allowed to apply custom document access control or is
the writer's group enough?
Do we need both read and write or just read since we have other
validation tools in place? Are there performance/efficiency concerns
here?
Should we expand HEAD responses to include more information relating
to security?
> 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.
Exactly. I think multiple databases serves the purpose best here. If
you need to box data up you can replicate to by-user-filtered
databases or just keep separate databases to begin with.
In the end I think there are some elegant API's already in place that
seem like they'd be easy to transport as long as you don't make weak
assumptions of how security will apply (i.e. view results).
Right now I think a good route might be to experiment with
transplanting the db/_security API as a special document attribute. It
has simple semantics and could share the session system that the
database code paths use. It also avoids requiring JS to run any code
on requests.
There might be problems but I can't say we're better off not trying
something like this. Do others have ideas of how to take this work on?
Maybe a prototype could be built using a node.js proxy first.
Brian.
Re: Introducing Bram Neijt
Posted by Bram Neijt <bn...@gmail.com>.
Dear all,
Here is a quick status update on the per-document authentication work.
I've done some combining of knowledge and had some thoughts, I've put them on
http://wiki.apache.org/couchdb/PerDocumentAuthorization
I've decided that all this thinking has been more then enough, and
I've started to look at implementing security for the Pages[1]
couchapp.
Soon I hope to finish strengthening the validate_doc_update.js
function and start to work on making the _user database less readable
for the normal user. Any thoughts on that, feel free to mail me.
Greets,
Bram
[1] https://github.com/couchone/pages
On Mon, Nov 8, 2010 at 5:08 PM, Jan Lehnardt <ja...@apache.org> wrote:
>
> 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
> --
>
>
>
Re: Introducing Bram Neijt
Posted by Jan Lehnardt <ja...@apache.org>.
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
--
Re: Introducing Bram Neijt
Posted by sgoto <sa...@gmail.com>.
argh sorry, wrong link :) i hope this one works now :)
https://docs.google.com/document/pub?id=1NWZ9xhsQvUL24IDa4erYcEZwkoNH6m13fizn8_og0gY
On Thu, Oct 28, 2010 at 7:29 AM, Jan Lehnardt <ja...@apache.org> wrote:
>
> 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 <ja...@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 <be...@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 !
> >
>
>
--
f u cn rd ths u cn b a gd prgmr !
Re: Introducing Bram Neijt
Posted by Jan Lehnardt <ja...@apache.org>.
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 <ja...@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 <be...@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 !
>
Re: Introducing Bram Neijt
Posted by Sebastian Cohnen <se...@googlemail.com>.
nice example, the document is not public ;)
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 <ja...@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 <be...@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 !
Re: Introducing Bram Neijt
Posted by sgoto <sa...@gmail.com>.
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 <ja...@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 <be...@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 !
Re: Introducing Bram Neijt
Posted by Jan Lehnardt <ja...@apache.org>.
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 <be...@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
>>>
>>
>>
Re: Introducing Bram Neijt
Posted by Dave Cottlehuber <da...@muse.net.nz>.
re wiki -> I will add this in next few days.
On 27 October 2010 04:39, Benjamin Young <be...@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
>>
>
>
Re: Introducing Bram Neijt
Posted by Benjamin Young <be...@couchone.com>.
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
>
Re: Introducing Bram Neijt
Posted by Adam Kocoloski <ko...@apache.org>.
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
Re: Introducing Bram Neijt
Posted by Jan Lehnardt <ja...@apache.org>.
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
--
Re: Introducing Bram Neijt
Posted by Fedor Indutny <fe...@gmail.com>.
Hi Bram, everybody!
I'm interested in per doc auth too. If I can help you in anything, feel free
to ping me!
2010/10/26 Bram Neijt <bn...@gmail.com>
> Hi everybody,
>
>
> 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.
>
> I've chosen to have a go at per document authorization for couchdb.
>
> 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.
>
>
> Looking forward to making a contribution,
>
> Bram
>
--
Fedor Indutny
Re: Introducing Bram Neijt
Posted by Klaus Trainer <kl...@web.de>.
Hi Bram,
cool to see your interest in contributing to the CouchDB project!
AFAIK we currently don't have read authorization on a per-document
level.
For write authorization on a per-document level we've got validation
functions.
See e.g. here:
http://guide.couchdb.org/draft/validation.html
and also here:
http://wiki.apache.org/couchdb/Document_Update_Validation
Recently, there has been reported an issue with it when replicating:
https://issues.apache.org/jira/browse/COUCHDB-915
I haven't looked closely at it yet. However, it's really a major issue
if validation functions don't work properly with replication, and it
should get fixed then.
Maybe you wanna take this as a starting point.
Always feel free to ask questions or discuss with others in the #couchdb
chatroom at freenode.
Cheers,
Klaus
On Tue, 2010-10-26 at 11:51 +0200, Bram Neijt wrote:
> Hi everybody,
>
>
> 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.
>
> I've chosen to have a go at per document authorization for couchdb.
>
> 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.
>
>
> Looking forward to making a contribution,
>
> Bram