d...@couchdb,
There's been much talk about how to store user accounts in CouchDB
databases . There are a few questions about the model, and description
of how the default handler works.
Currently Admin accounts are specified under config on a per node
basis. See couchdb_httpd:default_authentication_handler/1 for the
implementation. By making your own alternate auth handlers, you can
setup user_ctx for validation functions.
To override couchdb_httpd:default_authentication_handler in your local
install, edit your local.ini and add a line like:
authentication_handler = {couch_httpd, my_authentication_handler}
to the [httpd] section.
Now you're ready to start hacking!
I'd encourage you to reuse basic_username_pw(Req), and
couch_server:is_admin(User, Pass) in your implementations. Once you've
database-lookup for usernames happening, you'll have to make a
decision about how to handle the case where the same username and
password combo works for both user and admin accounts.
Ideally you'd want to prevent collisions between admin and user
accounts. But you can't very well prevent writes to the local.ini
file, so... maybe they need different login endpoints. I'm not sure
what to do here, this is a sticky bit.
I'm interested in loading user creds from an "accounts" database
(specified on a per-node basis, for simplicities sake). To handle
encryption, we'll have to have a node-secret, which can probably be
uniquely generated by Couch on boot if it doesn't exist (of course,
over-rideable in local.ini)
Jason Davies has been working on a /_login screen, and an untamperable
cookie store, so that creds don't have to be loaded on each request.
Client-state ftw!
Untamperable cookies can be subject to session stealing attacks, so
they'll need to be run under SSL if security is important.
There's still the database-admin role to account for, so let's not
forget there are details unaccounted for here.
Hoping to kick off the conversation.
Chris
--
Chris Anderson
http://jchris.mfdz.com
