couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Davis <paul.joseph.da...@gmail.com>
Subject Re: Need feedback on validate_doc_read
Date Mon, 27 Dec 2010 17:13:09 GMT
On Mon, Dec 27, 2010 at 12:11 PM, Robert Newson <robert.newson@gmail.com> wrote:
> Firstly, the patch contains some whitespace changes (couch_db.erl line
> 122 and couch_httpd.erl line 66, and some spurious INFO logs,
> couch_httpd.erl line 129) that should be removed.
>
> Secondly, the patch appears not to protect document content held in
> views at all, correct? If so, I'm -1 on the patch as it stands. A view
> that emits the doc as a value would bypass this access control
> entirely, I think.

Also, include_docs=true should be considered as well.

>
> Thirdly, no tests.
>
> B.
>
>
> On Mon, Dec 27, 2010 at 4:46 PM, Paul Davis <paul.joseph.davis@gmail.com> wrote:
>> On Mon, Dec 27, 2010 at 11:09 AM, Bram Neijt <bneijt@gmail.com> wrote:
>>> Hi all,
>>>
>>> After getting to know erlang the hard way, I've found a place to put
>>> in a patch and hook up validate_doc_read code.
>>>
>>> I've got a patch which implements a validate_doc_read in the same
>>> manner as validate_doc_update is implemented. The patch is available
>>> at
>>> https://github.com/bneijt/couchdb
>>>
>>> Things that are still on the TODO are the following:
>>> - Check the functioning when it comes to replication
>>> - Test the performance hit this will have on the server
>>> - Create a configuration option to enable or disable support for this
>>>
>>> An even bigger question is: is this a feature we would ever want in
>>> the mainstream couchdb releases? Is this something the couchdb team
>>> would like to support?
>>>
>>> But appart from that question, I would love some feedback on the
>>> implementation, the erlang and structure of it all, so please consider
>>> checking it out and posting some comments.
>>>
>>> Greets,
>>>
>>> Bram
>>>
>>
>> Skimming that last commit everything looks sane. The answer to whether
>> we'd pull something like that into trunk pretty much depends on your
>> three questions. It was never implemented because we assumed that it'd
>> be a performance killer and no one wanted to try it out to see how bad
>> it was.
>>
>> I'm not sure I'd like it to be configurable though. Being able to turn
>> something like that off doesn't seem like a good idea. Though, making
>> sure that the case where no design doc has a validate function doesn't
>> hurt performance would be close enough for most people I think.
>>
>>>
>>> On Tue, Dec 7, 2010 at 1:18 PM, Bram Neijt <bneijt@gmail.com> wrote:
>>>> Dear developers,
>>>>
>>>>
>>>> After going into the theoretical depths[1] of what performance hits
>>>> there may be and how replication will be affected, I've decided to
>>>> just implement a simple solution and see how far I can get.
>>>>
>>>> I've decided to try to implement a validate_doc_get function, in the
>>>> same manner as the validate_doc_update has been implemented. I've been
>>>> reading the code and I've gotten as far as finding
>>>> prep_and_validate_updates and handle_doc_show and I'm now thinking of
>>>> copying and pasting some logic in to see where it gets me.
>>>>
>>>> I would love some advice on the matter and welcome any comments/feedback.
>>>>
>>>>
>>>> Greets,
>>>>
>>>> Bram
>>>>
>>>> [1] http://wiki.apache.org/couchdb/PerDocumentAuthorization
>>>> PS If properly implemented, validate_doc_get will not fix all problems
>>>> and you will still need a firewall like system, however it may give
>>>> some insight into where to go from there.
>>>>
>>>
>>
>

Mime
View raw message