In a traditional RDBMS scenario, my app would "log in" to the DB using a single username/password combo and my app would implement authentication/authorization based on records within a table (for example). In CouchDB, there seems to be lots of discussion on using documents in the "_user" DB as users and managing authorization using the session token from the CouchDB server.
My experience has always been that I use a single username/password to authenticate my app to the database and work with security on top of that. I'm not sure I know how to implement a solution where I can't even get a connection to the database until I know who I have logged in. The documentation on CouchDB seems a tad scattershot (I've been reading the CouchDB guide linked to this morning with great interest, though...thanks for that!), particularly on authentication and authorization. The idea that everything is accessible scares me a little because I'm worried I won't get everything turned off to prevent XSS or some other attacker from getting their grimy paws on customer data. I'm trying to find a balance between allowing my application to access the couch server as code (which is easy when I'm using a single user/pass combo), but also allowing client-side JS to use the couch API directly. I guess what I'm wondering (out loud) is whether my server-side code should act on behalf of the logged-in user or as it's own "root" user? Using the REST API directly from client-side Javascript would seem to need to authenticate directly to the DB as a real user, while server-side code probably needs some kind of "admin" user, right? Thanks! J. Brisbin http://jbrisbin.com/
