This page forms a summary of the problem and possible solutions, it does not reflect current CouchDB features.

Introduction

CouchDB has a good HTTP API which encourages you to put your client applications in direct contact with your database. However, most dynamic systems require some kind of authentication and authorization. Per database there is the possibility of using Authentication and Authorization. This wiki page tries to summarize the possible solutions to using per document authentication and authorization.

Note: CouchDB has not be designed to support per-document read-control, and such a feature is not on the Roadmap. If you are reading this page, you should probably start thinking about using a database-per-security-group approach. In this model you create a database for a project, and grant only a certain set of users access to read and write to it. Filtered replication can be used to create subsets of a larger database when fine-grained control is needed.

The user is authenticated using any kind of authentication method (HTTP basic auth, or otherwise) and is considered to be identified by a single identifying string. Under the term "specific access", this document considers three types: being able to verify existence, being able to read the document, and being able to update the document (deleting the document is considered an update of the document)

Possible solutions

Database per user

Create one database for each user and use authentication on the database for that given user. Because views do not work across databases, you will have to replicate all needed data between the different user databases to allow for a view to contain both private and public/other users' data. Because normal users can not create/delete databases, you will need to have a separate process running which watches your database for changes and creates a new user database when a new user registers.

Access protection this solution implements:

Limitations:

Smart proxy

Create a smart proxy that wraps all documents with the user credentials and filters all results. Access protection this solution implements:

Limitations:

Document encryption on a per user basis

This solution is described in a google document which was mentioned on the development mailinglist. The goal of this solution is to create a P2P like system, where you can replicate data to nodes which you don't trust.

Access protection this solution implements:

Limitations:

Validate_doc_read function

Have a javascript function be called on every read, in the same manner as the validate_doc_update system is applied. A patch has been posted.

Access protection this solution implements:

Limitations:

See also