couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Anderson <>
Subject Re: Initial couchdb accounts feedback
Date Thu, 14 Jan 2010 16:54:39 GMT
On Thu, Jan 14, 2010 at 1:38 AM, Brian Candler <> wrote:
> Some more thoughts about the "_users" database.
> (1) It has been suggested in another thread that one user may have multiple
> identities - in particular, multiple openids - and want to be able to login
> with any of them.
> Or, someone could sign in with an E-mail address initially, and then want to
> add a second E-mail address to their account, because they are changing
> E-mail provider.
> Now, if the _users database were not queried directly, but instead via a
> view, this would allow the flexibility to have different structures, e.g.
>    "_id":"0cf34232937c7d2a",
>    "identities":["",""]
> I think this solves the replication problem nicely too. If two different
> users have username:"bob" (but different uuids), then after replication a
> login query will return two rows, and they won't be able to login.  The
> admin can fix this easily, either by altering one of the identities, or by
> deleting one of the user documents.

I'd rather treat conflicts as conflicts. I've got on my list of TODOs,
to make conflict docs ignored for purposes of login.

> The major flaw with this idea is that you can't prevent dupes at signup,
> since validate_doc_update can't check a view first.
> (2) Given that there are different types of identities, it might make sense
> to namespace them:
>        "login:fred"
>        ""
>        ""
> Having said that, I don't expect that the user with E-mail
> would be different from the user with openid - and if they
> were, it would be a bit confusing.
> (3) In principle it's easy to plug in so that the identities can be
> validated if required.  For example, an external process which validates
> that you have E-mail could E-mail you a message containing a
> signed token which says you own We block users adding
> an "email:..." identity without this token.
> Doing that requires some way of validating the token in validate_doc_update.
> * We can't use a hmac_sha1 + hardcoded secret, because anyone who reads the
>  _design document will know the secret
> * Doing RSA signature verification in Javascript could be tricky
> * Both may be expensive in Javascript
> * In any case we don't want to hardcode individual keys in the
>  server's validate_doc_update function
> I can think of several solutions. One is that a server secret is passed as a
> parameter to validate_doc_update (perhaps as part of the "security context"
> mentioned before). Another is that the server checks some field of the
> userDoc for a signature, and strips it if it's not properly signed. There
> are probably better ideas floating around.
> I think what's needed is something *like* a cookie, which can be generated
> by an external process and validated by couchdb.  Perhaps even the existing
> cookie auth mechanism could be overloaded/abused.  Put simply:
> validate_doc_update won't let you create user "" unless it
> sees that you are already logged in as "". That's trivial to
> implement.
> (But this gets complicated for multiple identities, as you would need two
> cookies at once to add your new ID to your existing reecord).
> At worst, you could always have an _external handler which knows the _admin
> credentials to the database, which in turn makes a HTTP call back to couchdb
> to modify the user record.  I feel uncomfortable with couchdb eating its own
> tail in this way.
> Since my app creates a new database per user, the 'signup' process would
> ultimately have to work this way anyway, I think. But this shouldn't be
> necessary for adding users to an existing database.
> Thoughts?

This is all to complex for my just awakened brain. I don't think
there's anything wrong with what you've just described, but it gets
some of the complexity in the wrong places. The validate_doc_update
function will just get a bare bones userCtx (name and roles) so adding
other structure to the users db won't effect it. If your app has users
which shouldn't be able to save documents until they have clicked a
link in their email, then you should have a role of "email
confirmation pending" and when the user clicks the link, some
admin-level software can remove that role and add a "confirmed" role.

I think we'll be able to support you, but I'll be trying hard to keep
the stuff Couch ships with as simple as possible. The goal is to make
the kinds of workflows you describe easy to layer on top of the
default system, while maintaining security and scalability.

> Regards,
> Brian.
> P.S. In my current application (with its own user docs) I also store user
> preferences, e.g.  timezone, full name.
> As far as I can see, the _users validate_doc_update lets you add arbitrary
> data to the _users database, e.g.
>    "foo_app_prefs":{"views_per_page":10}
> Would that be considered legitimate use for it, or is it likely to be locked
> down in future?

I think it is better practice to store app specific profile data in
another database. If you have site-specific profile data, it'd be OK
to store it in the users db, but I'd still encourage you to use an app
"site-profiles" and a db for that sort of thing. Maybe the users db
will be locked down in the future (that may end up being a site


Chris Anderson

View raw message