Posted by Lena Herrmann Thu, 29 Apr 2010 10:40:00 GMT

I recently wrote a testsuite for CouchDB’s Javascript HTTP API. Among the things I tested were the security methods. That’s those that deal with authentication - like signup, login, logout and so on. The challenge was to make sure my tests wouldn’t interfere with the CouchDB setup of the person running the tests.

Background

CouchDB stores the information about the database users in a special database, the authentication_db. The default authentication_db is called “_users”. So this is where your user data is saved when you sign up without taking care about the details, e.g. when you use the signup method provided by the JQuery HTTP API. Read more about the ways to interact with the authentication_db in the HTTP API documentation (JQuery methods), and read more about general CouchDB security in the CouchDB Wiki or in The Definitive Guide.

How to set the authentication_db

When you e.g. create database users from within your tests, how can you make sure they don’t mess up the actual authentication_db, the one the unsuspecting user might use in production? Of course you have to create a custom authentication_db for storing the user information, and make CouchDB use that one. And after your tests are finished, you want CouchDB to use the original authentication_db again, so that only your testsuite uses the custom users database.

So there is one function you call right at the beginning of the part of the testsuite that’s concerned with security features:

function useTestUserDb(){
  test_users_db = new CouchDB("test_users_db");
  var xhr = CouchDB.request("PUT", "/_config/couch_httpd_auth/authentication_db", {
    body: JSON.stringify("test_users_db")
  });
  if(typeof(old_auth_db) == 'undefined'){
    old_auth_db = xhr.responseText.replace(/\n/,'').replace(/"/g,'');
  }
}

We create a custom authentication_db (“test_users_db”) and write its name into the CouchDB configuration. If we don’t have the name of the old authentication_db stored yet (the one that’s called “_users” per default, but might be called differently), we strip this name from special characters and store it in a variable, so we can restore it later. This is the function we call at the very end of the testsuite:

function useOldUserDb(){
  CouchDB.request("PUT", "/_config/couch_httpd_auth/authentication_db", {
    body: JSON.stringify(old_auth_db)
  });
  test_users_db.deleteDb();
}

In the last line, we delete our custom authentication_db. Everything is back to normal, there is no trace of our tests left. You can have a look at how it looks like in production.

How to work with the authentication_db

You can create a new user like this:

var userDoc = CouchDB.prepareUserDoc({name: "Gaius Baltar", roles: ["president"]}, "secretpassword");
test_users_db.save(userDoc);

Then you are logged in and can do whatever you want. About working with users and roles, read the chapter in The Definitive Guide. When you’re done, delete the userDoc from the authentication_db, as the authentication_db has to be empty before it can be deleted:

test_users_db.deleteDoc({_id : userDoc.id, _rev : userDoc.rev})

no comments |

Trackbacks

Use the following link to trackback from your own site:
http://lenaherrmann.net/trackbacks?article_id=14

  1. Social comments and analytics for this post From uberVU - social comments
    This post was mentioned on Twitter by kilaulena: Another little blogpost: How to change the CouchDB authentication database. http://bit.ly/9XwbzJ

Leave a comment

Leave a comment