I’m working on an html5 application built on CouchDB. I want to make sure I set up the user data in the best way possible.
I’d like to use an email address in the “name” field of the user documents in the _user database. Like so:
{
"_id": "org.couchdb.user:John",
"_rev": "1-e25df7d685c35dbeb8dabb2453adebe8",
"name": "john@test.com",
"salt": "32ef0f8b1651e0638080afc76d0111d6",
"password_sha": "3023d37579fee19acd01d88c3ae1921a000418d7",
"type": "user",
"roles": [
]
}
The reason I would like to do this, is because an email address is a very unambiguous thing to ask for at sign up, and it is guaranteed to be unique amongst users. It requires the least amount of thought on the part of the user, and it’s super simple. There’s a problem though. If the _user database is public, then so are the email addresses in the user documents as far as I can tell. How can I overcome that?
Should I make the _user database private (readable and writeable only by admins?)
Should I store user data in individual user databases, and if I do that, how can my applications then pull that data efficiently. If I have several user’s data displayed on one page, with other data from other databases doesn’t that start to become really inefficient?
A little lost here, would love to know how some people have dealt with private user data.
I haven’t used couchdb, but I just did some reading in response to your question…
I read the Security and Validation section of the Technical Overview.
Also the wiki: Security_Features_Overvie — Authentication_database
_id and name must match As the wiki says:
Thus
However
Authentication and Access Control of _user doc
Re should _user db be private? Yes, it must be private. Also, in the current version of CouchDB, the user db has special security and access controls. This was done to take care of the same issues that you are struggling with.
From the same authentication database section of the wiki:
This means that your software can enable people to create new accounts safely. Once they are authenticated, they can only view/modify their own _user information.