On Mon, Dec 27, 2010 at 12:11 PM, Robert Newson <[email protected]> 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 <[email protected]> > wrote: >> On Mon, Dec 27, 2010 at 11:09 AM, Bram Neijt <[email protected]> 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 <[email protected]> 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. >>>> >>> >> >
