couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Benoit Chesneau" <bchesn...@gmail.com>
Subject Re: uuid, auto-increment, et al.
Date Mon, 20 Oct 2008 05:20:00 GMT
On Mon, Oct 20, 2008 at 6:47 AM, ara howard <ara.t.howard@gmail.com> wrote:
>
> i know counting objects, aka, distributed auto-increment in couch is
> consider bad form.  but let me propose a scenario a feel out peoples
> thoughts on a specific topic, in the interest in solving what i think *must*
> be solvable problem when using couch for an actual, real, live distributed
> system..
>
> so let's say we want to store something
>
>  login: foo
>  password: bar
>
> in a couchdb system, to authenticate users.  clearly, when given a login, we
> want to lookup a given login by said login and validate a password.
>
> so consider this a bit - we could store docs using "account-#{ login }" or
> some other permutation of of the login name - the md5.. whatever...
>
> this obviously isn't great - two user signing up on two different nodes will
> cause a collision at replication time, but not at sign up time, meaning it'd
> be nearly impossible to actually create a system with multi-master nodes
> that would allow something as simple as user signup without crazy after the
> fact email resolution requiring a user to re-signup iff their login was a
> dup.
>
> okay, take two, let couch generate the uuid, and replication proceeds as
> planned.  all is well.  that is, until you want to authenticate a user...
> doing a search based on
>
>  emit( doc.login, doc )
>
> returns 14 results.  two of them have the same password.  which user *is*
> this client logging in?
>
> so this seems like a real wart: replication is *useless* without a better
> mechanism for generating uuids.  clearly we cannot expect a user to login
> via uuid, and clearly we cannot use the login, nor login:password combined
> as the uuid since that would create retro-active signup failures...
>
> so, in a situation like this, requiring a unique set of data across all
> replicating systems, what would the 'couch way' be?
>
> i think i'm stuck thinking inside a box and would love some insight to get
> out of it but, for now, i feel like the distributed and replicated nature of
> couch, while solving a host of issues, seems to open up vastly more
> complicated ones in the process.
>
> kind regards.
>
> a @ http://codeforpeople.com/
> --
> we can deny everything, except that we have the possibility of being better.
> simply reflect on that.
> h.h. the 14th dalai lama
>
>
>
>

I don't understand the point. When a user login, you could generate an
authentification/session token. Which could be easily replicated.
doc._id is the the id of sesion/auth and is an uuid generated y
couchdb. Users have their own doc :

{
_id : uid of user,
usename
password
}


This is what I do here :

User login, I check its login/password or openid via a view. Then
generate a session doc. So I could use this session token across nodes
(for now only one master an some read nodes).


- benoƮt

Mime
View raw message