couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Michael C. Libby" <>
Subject Re: limit view access
Date Sun, 25 May 2014 21:40:42 GMT
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 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 <
> 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

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