couchdb-user mailing list archives

On Mon, Oct 20, 2008 at 9:18 AM, ara.t.howard <ara.t.howard@gmail.com> 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