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