Question

I was wondering how to built a system in which users are able to send messages to other users. Of course everyone needs to be able to access only his inbox, so we need per-user database infrastructure for that. Following the example from http://guide.couchdb.org/draft/notifications.html, we see that users could just put the messages into the database of the recipient. Simple and effective.

But what if we do not want to allow the users to know the recipient database name? What if we want a system that will resolve the recipient’ database by looking on the to field of the message document (which could be the user name, totally unrelated to his database name):

{
    "to": "john.kowalski",
    "from": "jake.podolski",
    "subject": "hi",
    "message": "..."
}

It seems like a perfect task for additional tier, but then it would be no fun and not worth a question, so we’re gonna try and solve it with replication:

1. User puts message document in main database
2. Replication task (we would have a task for each user) fetches that doc using filter that filters _changes feed by to field. The name “john.kowalski” would be passed as parameter for filter function.
3. Document ends in recipient database.

However, this creates a problem, because main database would have to be visible to all users! So…what if we would be able to add user->main replication task as well, so that the messages would be picked up from user database transferred to main database and then placed in recipients database (oh lord, it’s getting complicated, we may already waste our time by trying to solve it this way, but let’s try).

1. User puts message document in his database
2. Replication task fetches that doc, but can’t use filter function of any kind, because the filter in this case is owned by user, and therefore cannot be trusted.
3. Main database validates the doc – it checks whether from field is the one that’s associated with the source database.
4. The replication task used in previous approach transfers document to recipient.

There is problem in third step here (without that step, users would be able to send messages impersonating any other users by filling bogus info in from field) – how are we able to pass additional data to validation functions, the only parameters there as far as I know are:

• old doc
• new doc
• user context (logged user name, roles, db to which document is being written)
• security object?

By loooking on replicator database functionality introduced in 1.1.0, we could pass user_ctx context to replication task. Would it be possible for this object to contain custom data as opposed to real user info? How would that affect the standard way CouchDB handles database access?

If that would be possible, the replication task would just have the recipient name filled as parameter under user_ctx, then validation function would use that value to compare with from field. There would be no way for user to ‘send’ message as someone other than he.

Answer 1

This question is similar to this question about CouchDB user creation.

As with that question, I am optimistic that my inbox database patch will make this all much nicer.