Mailing-List: contact couchdb-user-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: couchdb-user@incubator.apache.org
Received-SPF: pass (athena.apache.org: domain of bchesneau@gmail.com
 designates 74.125.78.145 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:to:subject:in-reply-to:mime-version
         :content-type:content-transfer-encoding:content-disposition
         :references;
        b=Wn2NsJbjoks6FD/5evztydPKb3nv2EnWaQZLy/PAxyowvKlXYib/YaLyAcKp5lGXMz
         CKM+gs95i1FshKTY15RB15GxjjK7lL8uGHxlHvuqx1q4c7Ih6X1FLS+mLjo6aiEDy5q3
         ULhqyHu45oZBrr+F5Fy1c/FP5G1/pTNcw7+dc=
Message-ID: <b7cd8ed10810200052vff1ee0cp3852bd7331075e64@mail.gmail.com>
Date: Mon, 20 Oct 2008 09:52:25 +0200
From: "Benoit Chesneau" <bchesneau@gmail.com>
To: couchdb-user@incubator.apache.org
Subject: Re: uuid, auto-increment, et al.
In-Reply-To: <430ECBEB-D4B8-485B-B81C-5C1D60E18F07@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
References: <3CA3C700-106B-4577-9ABD-BDD4B422FE14@gmail.com>
	 <CB678ECE-7737-4CA5-B866-D9D1A44C521A@gmail.com>
	 <430ECBEB-D4B8-485B-B81C-5C1D60E18F07@gmail.com>

On Mon, Oct 20, 2008 at 9:18 AM, ara.t.howard <ara.t.howard@gmail.com> wrot=
e:
>
> 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=3D'blah' and password=3D'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 consiste=
ncy
>> issues to deal with because replication is asynchronous. One way to do t=
hat
>> 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 should=
n't
>> use the username as a key). An ldap server or something like it. Equival=
ent
>> 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 synchrono=
us
>> 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=EEt