couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jon Brisbin <...@jbrisbin.com>
Subject Single user or every user gets own login?
Date Mon, 23 Aug 2010 19:14:59 GMT
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/







Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message