couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Benoit Chesneau" <>
Subject Re: uuid, auto-increment, et al.
Date Mon, 20 Oct 2008 07:52:25 GMT
On Mon, Oct 20, 2008 at 9:18 AM, ara.t.howard <> wrote:
> On Oct 19, 2008, at 11:34 PM, Antony Blakey wrote:
>> If you want to ensure that the username is unique at the time the user
>> enters it, then you need a central synchronous service. Using the
>> username/password as a pair isn't a good idea because it only takes two
>> naive/lazy users to use a similar password (based say on their username? :)
>> for collision to subsequently occur.

how it could occur, if you are sure this pair is unique. A username is
unique so is the association "username with password".

simple check :
if username='blah' and password='blah' ....

or even hash (username, password)  in this order. Anyway the reason
why your authentication token shouldn't be based on this pair is
because your user could change its password sometimes.

>> 3. Use couchdb in a single-writer multiple-reader scenario. If you only do
>> that for those activities that require uniqueness then you have consistency
>> issues to deal with because replication is asynchronous. One way to do that
>> is to switch a session to the writable server as soon as you need
>> uniqueness. The single writer becomes a bottleneck, but this is what I'm
>> doing because it matches my information architecture.

You could have also multiple writer node and lock a user to one
available writer node . Then synchronize writers nodes and reader
nodes. Pb is with views indexation currently it isn't distributed.
Until that you can just use on writer node.

>> 4. Use a central specialized server to check uniqueness and generate an
>> opaque userid token that you would subsequently use as a key (you shouldn't
>> use the username as a key). An ldap server or something like it. Equivalent
>> to the option above, but the single server only needs to deal with the
>> particular operations requiring uniqueness. It's still a single point of
>> failure, but I don't think you can get around that if you want synchronous
>> global uniqueness testing.
> a validating and complete treatment - thanks.
> so pretty much my thoughts exactly.  the further advantage that #3 has is
> that is means *nothing* has to be done up front, it's only when the app
> scales out the multiple dbs that work needs to be done but, at that time,
> it's presumably justified.  i've also considered #4 heavily (a possible
> great web service actually...)

A service based on oauth could do the thing. Ie one service that
manage association user/session token

- benoƮt

View raw message