couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian Candler <B.Cand...@pobox.com>
Subject Re: Initial couchdb accounts feedback
Date Thu, 14 Jan 2010 09:38:34 GMT
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":["fred@example.com","fred@example.net"]

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.

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"
        "email:foo@example.com"
        "openid:fred@example.net"

Having said that, I don't expect that the user with E-mail fred@example.com
would be different from the user with openid fred@example.com - 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 foo@example.com could E-mail you a message containing a
signed token which says you own email:foo@example.com. 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 "foo@example.com" unless it
sees that you are already logged in as "foo@example.com". 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?

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?

Mime
View raw message