couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From cinnebar <ccinne...@gmail.com>
Subject Re: Initial couchdb accounts feedback
Date Sun, 24 Jan 2010 05:57:52 GMT
On Mon, Jan 11, 2010 at 5:24 AM, cinnebar <ccinnebar@gmail.com> wrote:
>validate against a"'cat" field which effectively means that user is a type
of namespaced role and other roles are also values keyed by "cat"

this is false.
at the moment the relevent fields of the usr doc we are working with look
like this:

"cat":"usr"
"env":{"cat":[/*roles*/)], ...}

'usr' is a document category whereas 'env.cat' in a 'usr' document is a user
category.



On Fri, Jan 15, 2010 at 3:54 AM, Chris Anderson <jchris@apache.org> wrote:

> On Thu, Jan 14, 2010 at 1:38 AM, Brian Candler <B.Candler@pobox.com>
> 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":["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.
>
> 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"
> >        "email:foo@example.com <email%3Afoo@example.com>"
> >        "openid:fred@example.net <openid%3Afred@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<email%3Afoo@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?
>
> 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
> setting.)
>
> Chris
>
> --
> Chris Anderson
> http://jchrisa.net
> http://couch.io
>

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