views:

176

answers:

2

Document databases that support REST-style JSON over HTTP access seem ideal for supporting AJAX-rich applications where the browser is making direct calls to the database, bypassing the traditional web server / application logic components. An example of this might be retrieving user preferences once a user has been authenticated. (BBC Homepage might be a good example of this, prior to crashing under the load!)

The problem with this scenario is the security issue - if a user is authenticated using a web server (e.g. basic forms authentication), how is this identity carried over to the document DB. Is the only answer to proxy all requests to the DB through the web server anyway - i.e. secure the document DB so that there is no direct external access?

This seems to make most sense, and is the easiest to implement, but I was wondering whether anyone out there had an experience and / or advice on using document dbs in a heterogeneous environment?

+1  A: 

Well, I only have experience with CouchDB, but hope I can help you nonetheless.

CouchDB has a validation process built-in, you write your validation rules in javascript, and have access to the group in which the current user is. It's all handled by CouchDB itself basically, you don't have to care how you get to login information.

commandoline
+1  A: 

This probably differs in every database you mention. Here's how it works in CouchDB.

CouchDB allows you to manage users and roles.

You can use the validate_doc_update function in your design documents to restrict document creation/update. For example, you can write a validation that denies document update to anyone but its author.

To restrict who can read documents from a database, you can edit the /db_name/_security document and list the users or roles.

However, I don't think you can make the read access more granular (i.e. allow a user to read only the documents they created).

To achieve that, you have to put the CouchDB behind a proxy and use views to serve the documents to authenticated users. You can still use CouchDB user management this way. The proxy just hides the direct access to the database.

For more detailed info, check the security overview on CouchDB wiki, the security chapter of the Relax book and this short screencast.

Tomas Sedovic
I think read access restrictions are on the list for a future release.
stwissel
The key seems to be the proxy - I think that attempting to build an entire web stack on top of CouchDB is too ambitious at this stage (unless it's a very simple app) - running it behind the proxy makes most sense, and this works for us. We're running MongoDB, but all HTTP access is proxied through IIS - it just makes works.
Hugo Rodger-Brown