couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dave Cottlehuber <>
Subject Re: Document Security Design Question
Date Tue, 10 Aug 2010 18:05:54 GMT
On 11 August 2010 05:47, Ryan Ramage <> wrote:
> I have a couch app that I am building that now I have to start
> thinking about security. I will have documents that I need to restrict
> access to by users. So for a given document I have a set of users that
> can access the document, and a set that can't.
> Another condition of this scenario is the documents will have a large
> attachments with them, so I am trying to keep replication down to a
> minimum.
> Since couch db does not support fine grained readers in one db, I had
> the idea to create a separate db which has a sole purpose of holding
> the document. Then I would define the readers list for that db to the
> set of users.
> The issue I have is that when the time comes to create the document
> (and associated db), the user that will do it will not be a server
> admin. It will be the main user who is creating the document. I don't
> have a middleware layer, and I cant think of another way to do this.
> The only other way I can see is to have a user based db, and when a
> user commits a doc to it, it replicates to all other user with
> permissions, but I really don't want to be replicating the large
> attachments (that need to stay with the doc)...
> Anyone have thoughts on this?

a DB per doc seems overkill, you might as well store them directly on
a filesystem & serve up directly.

A better approach might be to have a master set of couches which hold
all data for all users, and then allow via filtered replication &
validation functions only docs that are tagged for your
user/group/function to filter to each local couch. You would then need
an additional method of controlling access to the master DB data,
perhaps either a proxy setup to prevent direct URL access for users,
or get the proxy to do authentication & control.

I am sure somebody's already got a design pattern for this.


View raw message