Yep, that's what I was talking about!
2010/11/29 Chad George <[email protected]>
> 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: [email protected]
Github: http://github.com/donnerjack13589
