On Mon, Oct 20, 2008 at 9:18 AM, ara.t.howard <[EMAIL PROTECTED]> 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
