Design pattern for preventing the assignment of duplicate login id's

[Itai]

Feedback appreciated.


Problem definition:

Two distinct users are in the process of filling out a three step
wizard type registration form. The first page requires choosing a
login id. Assuming the two users choose the same textual login id, the
wizard must assign the name to the first one who submitted the
request. However, since an entry in the database is created only after
successfully completing all wizard steps, this name must only be
assigned temporarily.

Following is the proposed solution:

1. Define a "log object" which hold uncommitted loginid's and place it
in the Application State object

2. Define a loginid entry in the Session State object to hold the
string representation of a chosen loginid

3. When the user submits the first page of the registration wizard:
3.1 Application.Lock()
3.2 Check if the name has already been placed in the "log object"
3.3 (if not) perform a db query for that name to check if already
assigned to other user (this should be quick assuming the login id is
the primary key).
3.4 Update the name in the "log object"
3.5 Application.UnLock()
3.6 Update the name in the Session State loginid entry
3.7 Resume normal wizard flow
3.8 Application.Lock()
3.9 Delete the name from the "log object" (this would be at the last
wizard page)
3.10 Application.UnLock()


4. In the Session_End event delete the appropriate "log object" entry
(in case of a timeout) using the Session State loginid entry as the
lookup key.

 

[MattC]

Why not just get the user to select a username on the last page, then when
you submit check if it exists and insert if it doesn't, store the data you
got so far in a class and wack that in the session when the attempted entry
fails due to duplicate entry unpack your session object and send them back
to the last page to pick a new one.

MattC

 

[Itai]

Why not just get the user to select a username on the last page, then when
you submit check if it exists and insert if it doesn't, store the data you
got so far in a class and wack that in the session when the attempted entry
fails due to duplicate entry unpack your session object and send them back
to the last page to pick a new one.

MattC

Ah, this is the simple case however, the logical flow of a typical
member registration wizard requires a user to choose a userid at the
beginning of the process. My proposed solution aims to solve three
problems:

1. ensure that the first user who looked up the name actually gets it
2. make the name available again if the user did not complete the
wizard
3. reduced db lookups during wizard flow if the name has already been
temporarily assigned to someone else

 

[MattC]

So as soon as they select the name do a check and if its free put an initial
entry into the table with a field to say that the user is not active yet and
the users email address and the date. Store the returned user ID in the
session. When the user completes their wizard entry simply used the ID to
enter the remaining details. If they get disconnected or time out, check
the session for the ID if not present ask for their email to resume entry.
Once done set the field to active. Also if they go away without completing
and never come back you know this by the active field being false. You can
free up usernames by frequently deleting inactive entries over a certain
date ago.

MattC

 

[Itai Itai]

"Also if they go away without completing and never come back you know
this by the active field being false. You can free up usernames by
frequently deleting inactive entries over a certain date ago."

My solution prevents this by committing the name to the db only upon
successful registration.

Furthermore, I don't do multiple updates to the database but only one
which commits entire user details upon successful wizard completion.

Review the solution for further details.

 

[MattC]

Then go with your orginal idea of keeping the userID of those in the wizard
in your application object.

Personally I'd leave the userID selection till the end like Hotmail does I
believe, that way you have all your wizard info in the session and you can
keep redirecting them back to the final page if they continually pick used
userid's, until they pick one that is unique and the wizard is then
complete.

But if your requirement is that it has to be at the beginning then you will
have to manage which names are being used.

MattC