Best practice for a multiuser CouchDB-based app?

Question

I create a CMS from scratch and decided to use CouchDB as my database solution. For my CMS I need various accounts and of course different user roles (admin, author, unregistered user, etc.).

First I thought I would program authorization within my CMS myself, but CouchDB has stuff like this build in, so I want to ask:

What is the best practice creating a multiuser app with CouchDB?

1. Create only one admin for CouchDB and manage restrictions, roles and accounts by yourself?
2. Use build-in functionality of CouchDB for all this? (Say create a CouchDB admin user for every admin of the CMS?)

What if I want to add other 3rd-party authorization later? Say I want users to login via Twitter/Facebook/Google?

Greetings, Pipo

Answer 1

The critical question is whether you want to expose CouchDB to the public or not.

If you want to build your CMS as a classical 3-tier architecture where CouchDB is exclusively accessed from a privileged scripting layer, e.g. PHP, then I would recommend you to roll your own authorization system. This will give you better control over the authorization logic. Particularly, you can realize document based read access control (not available in the CouchDB security system).

If instead you want to expose CouchDB to the public, things are different. You cannot actually write server side logic (except for separate asynchronous listeners via the changes feed) so you will have to use CouchDB's built in authentication/authorization system. That limits you to read access controlled on a database level (not document level!). Write access can be controlled with validation functions. CouchDB admins should not be equivalent to application admins as a CouchDB admin is rather comparable to a server admin in a traditional setting. A database admin in CouchDB would be a better fit (can change design documents and therefore make modifications to the CMS installation like adding plugins). All other users with write access can be realized as database members.

I would prefer the second approach, because this will give you the possibility to leverage all the nice features of CouchDB like replication and the changes feed. However, you will have to do some filtered replication between databases with different members if you need fine grained read access control.

If you want to use other authentication mechanisms than those offered by CouchDB, you will eventually have to modify the installation (which can be an issue if you want to use a hosted CouchDB). For a facebook plugin see e.g. https://github.com/ocastalabs/CouchDB-Facebook-Authentication.