On 11 August 2010 05:47, Ryan Ramage <[email protected]> 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. cheers Dave
