Professional Web Applications Themes

Design pattern for preventing the assignment of duplicate login id's - ASP.NET Security

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 ...

  1. #1

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

    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.
    Itai Guest

  2. #2

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

    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.
    Itai Guest

  3. #3

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

    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" <itaitai2003> wrote in message
    news:429f6e7d.0408110253.3ad83b3eposting.google.c om...
    > 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 Guest

  4. #4

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

    "MattC" <mm.com> wrote in message news:<#Ucc6y6fEHA.3192tk2msftngp13.phx.gbl>...
    > 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
    Itai Guest

  5. #5

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

    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" <itaitai2003> wrote in message
    news:429f6e7d.0408112118.1d136e3fposting.google.c om...
    > "MattC" <mm.com> wrote in message
    news:<#Ucc6y6fEHA.3192tk2msftngp13.phx.gbl>...
    > > 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 Guest

  6. #6

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


    "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.



    *** Sent via Developersdex [url]http://www.developersdex.com[/url] ***
    Don't just participate in USENET...get rewarded for it!
    Itai Itai Guest

  7. #7

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

    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

    "Itai Itai" <itaitai2003> wrote in message
    news:#J14bZHgEHA.3944tk2msftngp13.phx.gbl...
    >
    > "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.
    >
    >
    >
    > *** Sent via Developersdex [url]http://www.developersdex.com[/url] ***
    > Don't just participate in USENET...get rewarded for it!

    MattC Guest

Similar Threads

  1. design pattern
    By san00001 in forum Macromedia Flex General Discussion
    Replies: 0
    Last Post: May 15th, 11:10 AM
  2. Replies: 42
    Last Post: May 31st, 06:26 PM
  3. Replies: 3
    Last Post: September 12th, 08:20 PM
  4. preventing duplicate row insertion from asp.net app
    By aboesteanu@yahoo.com in forum ASP.NET General
    Replies: 2
    Last Post: August 11th, 07:56 PM
  5. Replies: 8
    Last Post: July 5th, 08:42 PM

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139