JD on EP

i've often wondered about that possible race condition on sites that have ajax-y name availability checks. i'm tempted to launch two browsers next time i see a registration form like that and try it out :)

To be fair, running that synchronously still has the same problem (in a browser application). Unless the potential username is locked, (and unlocked appropriately), and additionally the username is always re-verified by the server/db when actually chosen, Ajax, Flash, Html - they all have the same issue.

I'm not really a pro-Ajax person (I'm not against it, but I'm certainly not an evangelist), but the issue here is not Ajax [jd sez: Yes, it's not a difference in clients; it's asynchronous handling in general] - it's the (lack of) validation of user input. There's no reason an Ajax or non-Ajax application couldn't handle that race condition somewhat intelligently.

I've got one better...an registration process that gave you a list a potential usernames when the one you wanted wasn't available, but neglected to check the availability of the suggested names. I can't really post a link, but imagine...

Me: I'd like "Jason".
App: Sorry, "Jason" is taken. Try "Jason1".
Me: Ok, give me "Jason1".
App: Sorry, "Jason1" is taken. Try "Jason".

Party...

Hi John,

Sure, locking is one solution, but there is another that's easier to code: impose a minimum length increase on the revised name. The number of additional characters should be determined by expected number of simultaneous users.

So for example, if we allow only lower case letters and digits in the user name, there will be 36 possibilities for each character. Thus, if we expect to have 100 simultaneous users trying to create a user name, we would want to have two additional characters added to revised name since 36^2 > 100.

Interaction would go something like this:

You: I'd like "Jason"
Web App: Sorry, "Jason" is taken - try adding two additional characters.

If two users get to this point, the likelihood that both will add the same additional characters will be 1/36^2.

Of course users will tend to add characters/numbers that have significance to them (e.g. year of birth) and that would lead to a higher probability of name collisions than 1/36^2, but that can be compensated by requiring additional characters on top of those.

This technique isn't guaranteed, but it should work most of the time, and it is certainly easier to implement!

Thanks,
Mike K

JD,

I think what I was trying to say (without actually saying it) is that _any_ execution in a browser is asynchronous, whether it's Ajax, Flash, or a standard get/post request...which I think you picked up on, as per your in comment comment. ;)

A very interesting site, I think. The Idea of Technology was new for me but worth to be read and thought abot it (although I'm not a native english-speaker and have some difficulties whith this language)