CreateUserWizard (almost) Figured Out – Part 1

While developing an outward-facing portal web site for a client, I had need to use the ASP.NET CreateUserWizard (CUW) control in Visual Studio 2010 (it is essentially unchanged from previous versions).  This control really does make it easy to create new users.

This series of posts will demonstrate my hard-won lessons on how to make this control do your bidding.  This initial post will provide the overview of the problem and the design.  The next post will cover the .aspx page with the CUW control declaration.  The final installment will cover the code-behind.

But like so many other software objects extant (e.g. Windows and Office), the CUW is designed out of the box to give good demo, not perform real-world work.  If you adhere strictly to their paradigm of user name, e-mail address, password, etc., with no additions or subtractions, it is incredibly easy to create a valid, secure, persisted user with zero coding.  Drag and drop a control, and bang! It just works. 

You can test this yourself by dragging a CreateUserWizard control from the toolbox onto a web page, run it, and create a user. You can verify that the user was created by opening the WAT in Visual Studio to see the new username listed.

Of course, it is a bit disingenuous  to say “zero coding”. Although there is no coding required in either the .aspx or the .aspx.cs files, there is some effort required in web.config to set up the security database properly, unless you use the standard default security database.  I’m not going to go into that here, but will just assume you have that part already working.

In any event, real-world implementations are rarely so cut and dried.  Business requirements intrude. For example, perhaps you need to perform some other verification before allowing a person to create a new user account. 

In the case of my client’s portal, we had to first determine if the new user had a pre-existing account in the corporate database, and if yes, if she also had a ShortTermStatus of “Active”. (ShortTermStatusID is a foreign key field in our db, with a half dozen possible values.)  If so, she is allowed to create an account into the portal. If not, she is informed accordingly and turned away.

Furthermore, to help ensure that a person is who they say they are, we ask for First Name, Last Name, and Phone Number, along with the already required E-mail address.  Then we find the person with that E-mail address (this requires that the E-mail address be unique in the corporate database), and compare the names and phone number. If everything matches, we allow the new user. (The actual comparison was also not quite as simple as one might initially think.  For example, we allow the First Name entered here to match either the FirstName or NickName fields on record, and the phone number entered can match any of several phone numbers on record. )

So these requirements mean that a database lookup needs to be performed before the new user is created in the security database.  If she is not qualified, the new user is never created.  If she is qualified, her PersonID from the corporate db needs to be conveyed and stored in the security database, so that the user can later log into the portal and see her live data.

One more thing: we wanted the regular users, but not necessarily admin people, to use their e-mail address as their username. In fact, when logging in, they are not given the opportunity to enter an identifying field other than their e-mail address (and password, of course).  It was felt this would make it easier for the users to manage their accounts.

This all should be easy enough, but it turns out to be surprisingly tricky to get it all right. 

And I still don’t have it perfect:  I have not yet figured out how to explicitly declare the Create User and Cancel buttons.  This is both esthetic (I would like to reposition the buttons) and functional (I would like to set the Cancel button CausesValidation = false).  It should be solvable – I have just not yet found the proper steps or syntax to access the correct template.

Here a screen shot of the final product in IE8 (without any styling applied, for brevity of the example):

A few things on this page bear note. There is no field called UserName, although the CUW requires just such a field; there is no choice in that matter.  Next, the E-mail address is asked for twice, including a confirmation field.

This latter is actually a hack.  The first E-mail address text box is actually the UserName, as far as the CUW control knows, as you will see in the control declaration in CreateUser.aspx, seen in the next installment.  Its ID attribute is “UserName”, while the ID attribute of the Confirm E-mail textbox is “Email”.  The CUW control requires both of those fields, with those exact ID’s. (You can change the ID required, but it is not usually worth the effort.)

<digression>
On the Admin page, where users in other roles can be created, the UI does ask for and recognizes a UserName as UserName.
</digression>

Using the information presented here, we do a lookup into the corporate database, by calling a stored procedure which returns a PersonID if the person exists in the database, and an error message either if she exists and is not valid or does not exist at all.

This thrilling tale is continued in Part 2 – The .aspx File

Posted in Software Development | Tagged | Leave a comment

Fast OnLine Data Entry (FOLDE)

In recent years, many apps have migrated to an online model – browser apps, phone apps, cloud-based services, and so on.  And with good reason: we value our mobility, the ability to work anywhere (he says as he writes this while sitting in an auto dealership waiting room), and freedom from onerous installation, configuration and maintenance issues. With ubiquitous broadband internet connections, improving mobile phone speed, and maturing client-side browser capabilities, the previous shortcomings of online apps are receding in the rear view mirror. 

But for fast production data entry and complex user interaction (picture a customer service rep talking to customers on the phone, editing in real-time), online apps still come up short compared to traditional installed applications.

There are several major issues at play:

  • Usage scenarios
  • Round trips between user and server 
  • User interactivity
  • Business logic
  • Saving data

Each of these items by themselves is a big topic, and there are other issues as well.

 For the past several years, I have been developing browser apps which implement fast online data entry, or FOLDE, for short.  FOLDE apps use various design techniques, client side programming in the form of Ajax and JavaScript, and database optimization to satisfy the speed and accuracy requirements of production data entry while still allowing use from any computer connected to the internet. Not only does this make life in the office easier, but allows users to do their work from anywhere, whether at home, the local coffee shop or an internet cafe on the other side of the world.

I will be exploring each of these issues in more detail  in upcoming blog posts.  I would be very interested in hearing from others on this topic.

Posted in FOLDE | Tagged , | Leave a comment