couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Fedor Indutny <>
Subject Re: Per Document Filtering/Authorization
Date Mon, 29 Nov 2010 14:20:34 GMT
Yep, that's what I was talking about!

2010/11/29 Chad George <>

> 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

Fedor Indutny.

Skype: fedor.indutny

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message