Thanks Jens, Sebastion, Joan, and Cameron for your responses! This confirmed what I found on the wiki, but was sort of hoping was outdated... or that I was missing something obvious.
I did find that the problem isn't even as simple as it first seems, given that attempting to put in access control would have a big impact on the semantics of map/reduce in a way that probably creates more problems than it solves. Middleware/proxy seems like the way to go and that's the approach I'll take. Of course... it leads one to wonder if there's a way to hook into MochiWeb's request/response cycle? From http://couchdb.readthedocs.org/en/1.4.x/configuring.html it seems like this is extremely limited and probably not a better solution than middleware. Thanks again! On Sun, May 25, 2014 at 9:49 AM, Michael C. Libby <[email protected] > wrote: > Perhaps my fundamental security model is wrong, but where I am at is: I've > got a view that leaks information and I'd like to restrict access (perhaps > by providing default parameters server-side). > > The use case: I have docs in a database that I want to share between > users. The users access for each doc falls into "owner", "writer", "reader" > and "forbidden". I am tracking the users' access in the doc itself and > using validation to prevent inappropriate updates and using shows to filter > the access properties out of the docs (if there is a way to have a regular > GET not include some doc properties, I'd love to know). > > The goal is to make sure that no user can see who the other users of the > doc are. Also, they should only know about docs they have access to and > whether they have read or write access. > > So I set up a view that links each user to the doc > '/db/_design/docs/_view/by_user', but obviously in the default state, this > view shows all the users and all the docs. What I'd like is a way to > prevent users from getting results that are for a user other than > themselves. > > Any advice? > > Thanks, > m. libby >
