How to create a users database in a couchapp with per user database security model? (per document read access)

Question

Hi I read about two ways for implementing per-document read access for couchapps:

1. Each user gets his own database which contains only data this user is allowed to read. Then all users write to a master database that replicates to all user databases using a replication filter that decides who can read what.
2. Using list functions to filter the output of other views and to restrict access via a proxy server and a whitelist.

I have some questions about this:

1. Are there more possibillities to acieve read access on document level?

2. How do i create a users private database in a couchapp? i do need admin rights for that but a user who fills out the signUp form of my application clearly can't have admin rights. do i need a middle-layer (php etc...) for the signup process so that i can create the database needed?

3. When i finally have this database i need to start continous replication using a filter. somewhere i read that such replications are not resumed when the server is rebooted. do i need a chronjob that recreates these replications ever x hours for the case that the server crashes??

4. isn't that a huge waste of disk space? most of the data gets duplicated for every user that registers for my application or am i wrong? (especially if there is only little information that must not be read by others)

Answer 1

1. I know of no other way that is immediately workable, besides for example modifying the CouchDB source code. One possibility is to use the trunk (or v1.1 when it is released) which may have an externals API. Externals are web servers CouchDB will forward some connections to.

2. You need a third layer, but not necessarily a middle layer. Your external software will connect to CouchDB as an admin and perform tasks that are pending. For example, when a user needs a new database, they create a document in a public DB, then the external software will create the database, assign the user as the admin, etc. It is very easy to do this by querying /_changes?feed=continuous because you get a real-time feed of updates from users. I prefer this instead of a middle layer because the software is simpler (no extra web development, just CouchDB GET and PUT) and it can crash, restart, be upgraded, etc. without much impact to the users.

3. A cron job is not a bad idea anyway. Hey, it could be part of your external processor from step 2 above! However, beginning with CouchDB 1.1, replications will restart after a couch restart.

4. It should not waste much space. Depending on your application, you want to get all shared data in a shared database, and all private data in a private database per user. But even if you have duplicates of the data, I would not call it a waste. Disk space is a very small expense compared to developer effort or the intangible cost of security issues.

Depending on your application, you have huge opportunities in the future for mobile or offline features. When you release an iPhone, desktop, or offline webapp, users can work on a local replica of their database, then sync with the "official" database on your server once they are back online. For some apps, that is becoming a must-have features as people expect to use applications in any situation.