couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bram Neijt <bne...@gmail.com>
Subject Re: Per Document Filtering/Authorization
Date Mon, 29 Nov 2010 16:14:11 GMT
Yes, we could add something like _access to control access to the
document, however that would mean that the validate_doc_update
function will have to add this to the documents (you can't wait for
the user to add the validation function).

That makes it seem simpler to add an access function at the database
level, where you would still be able to do something like
"if(document.type == 'should_secure') { //heavy security for the
document }" with the added bonus of not having to replicate your
security code in all your documents.

Maybe we would be better of with a system that allows us to match
requests with user information, because we need something to protect
the view from unauthorized access as well? If somebody thinks that
would be a good idea, feel free to add a comment.

Please comment on the "per document access function" vs "per database
access function".

Greets,

Bram

On Mon, Nov 29, 2010 at 3:20 PM, Fedor Indutny <fedor.indutny@gmail.com> wrote:
> Yep, that's what I was talking about!
>
> 2010/11/29 Chad George <chad@mgproducts.com>
>
>> Bram Neijt has recently indicated interest in working on per document
>> authorization. I've mentioned an idea a few times here and on the user list
>> but never got any real response so I'm still not sure what the general
>> consensus about the idea is.
>>
>> My idea is to add a new special field on the document that indicates a
>> function that can modify the document before returning it to the user.
>> function(doc, req) {
>>  /* modify doc based on req or just throw exception */
>>  return doc;
>> }
>>
>> I think the main place that document authorization is needed is limiting
>> (or
>> sanitizing) access to raw documents. Especially in a mixed authorized
>> and anonymous access environment.
>>
>> Shows/Lists/Updates are already pretty easy to enforce a security barrier
>> within a single database, but direct access to documents makes certain
>> applications difficult (or impossible) to secure without a middle server
>> layer.
>>
>> With a filter function attached to the document, we would have minimal
>> overhead for when doc auth wasn't required so only secured documents would
>> get any real performance penalty. By allowing the filter function to return
>> a modified document --or-- throw an exception we could get access denial
>> and
>> minor sanitizing with the same mechanism.
>>
>> This would work nicely with include-docs for views that need security. And
>> it doesn't seem that hard to keep secure info out of being embedded in
>> views
>> and view reductions in the first place. I recently saw a suggestion on the
>> mailing list to have an access control function for views on the design
>> document, that seems like a nice fix for securing access to views
>> themselves.
>>
>> - Chad
>>
>
>
>
> --
> Cheers,
> Fedor Indutny.
>
> Skype: fedor.indutny
> Gtalk: fedor.indutny@gmail.com
> Github: http://github.com/donnerjack13589
>

Mime
View raw message