You can find it on MSDN here, or on my blog here.

Here is the introduction.

Introduction

This article extends one of the web pages developed in Part II of this series using Microsoft’s implementation of AJAX called Atlas. It utilized two techniques for reducing web server traffic to the browser to enhance the users web experience. The first technique uses the UpdatePanel tags to limit the refreshed area of the web page to limited areas and the second has to do with implementing some javascript using Atlas techniques so that the web page is updated on every key stroke in a textbox. A user list is displayed based on what is actively typed into this textbox. After reading this article the developer will be able to implement AJAX (Microsoft’s implementation Atlas) in their own application.

Applies to:

• Microsoft ASP.NET 2.0
• Microsoft Visual Studio 2005
• Microsoft Internet Information Services

Run Live Demonstration Of Personalization in Membership Technology

Go to the Web Site to Create Your Own ObjectDataSource From Your Own Web.Config

Click Here for Source Code Associated With This Article

Microsoft ASP.NET 2.0 Member/Role Management with IIS, Part 2: Implementation

Contents

Introduction
Background
Why Do We Need This?
Adding Profile Information to the ObjectDataSource
Using the Profile Generating Website
Build A Simple Web Page
Conclusions

Introduction

This article extends one of the web pages developed in Part II of this series using Microsoft’s Profile feature. In Part II, the Membership API was encapsulated in an ObjectDataSource. This allowed the developer to have a drop in web page for the web site administrator to use in an web site project for editing membership. This tools allowed for similar capability to the the web site manager tool included in Visual Studio 2005 (VS2005). It is necessary because using that web configuration tool included with VS2005 is problematic and should not be used in a production web site.

This article explains how the encapsulation of Membership can be extended to include Profile (personalization) information for users. The designers of Membership included a very basic set of attributes to associate with Members (logged in users). The Profile API provided by Microsoft allows for additional information to be attached to each member. Typically, this information would include things like: first name, last name, home address, favorite color schemes or anything else the developer may want to associate with a logged in member. By personalizing the site to the member logged in, it likely increases the chance the user will return and be more comfortable while visiting.

Background

ASP.NET has done an outstanding job of making the profile information associated with a logged in user very easy to access programmatically. They have done this by using their Provider technology to create a typed class that the developer can access with intellisense property values. What does this mean? This means that the profile information is declaratively defined as XML in the web.config file. The example below shows the lines that have been added to the <system.web> section of the web.config.

 <system .web>
  <profile defaultProvider="SqlProfileProvider">
    <providers>
      <remove name="AspNetSqlProfileProvider"/>
      <add name="SqlProfileProvider"
       type="System.Web.Profile.SqlProfileProvider"
       connectionStringName="LocalSqlServer"/>
    </providers>
    <properties>
      <add name="FirstName" type="string"/>
      <add name="LastName" type="string"/>
      <add name="AdvancedMode" type="bool"/>
      <group name="Address">
        <add name="Street" type="string"/>
        <add name="City" type="string"/>
        <add name="State" type="string"/>
        <add name="Zip" type="string"/>
      </group>    </properties>  </profile>
</system>

These new properties defined by Microsoft can be accessed in C# at run time very simply. Below are a few lines of code showing how this can be done in a typical codebehind page. These lines of code are taken from the button update event on the page UpdateProfileSimple.aspx included in the download associated with this article.

 protected void ButtonUpdate_Click(object sender,
    EventArgs e)
{
  Profile.FirstName = TextBoxFirstName.Text;
  Profile.LastName = TextBoxLastName.Text;
  Profile.Save();
}

Profile is available everywhere because it is a static class generated from the Web.Config section shown above. Because it is an actual class, the properties FirstName and LastName are available from VS2005′s intellisense and are type safe. No incorrectly typing them and getting syntax errors.

In the simple example below (UpdateProfileSimple.aspx), it is necessary to first pre load the textboxes when the user logs in. This can be done in the pageload event as follows.

 protected void Page_Load(object sender, EventArgs e)
{
  // Only allow for profile update when a user is logged in
  MembershipUser mu = Membership.GetUser();
  if (mu == null)
  {
    ButtonUpdate.Enabled = false;
  }
  else
  {
    if (!IsPostBack)
    {
      TextBoxFirstName.Text = Profile.FirstName;
      TextBoxLastName.Text = Profile.LastName;
    }
  }
}

There are a couple things to notice in the above page_load event. First, if no user is logged in, the update button is disabled. This is because it would be meaningless to press the update button if there was no current user to update. It is important to mention that this article does not address dealing with anonymous users. That is a whole different topic. Very interesting, but beyond the scope of this article. Also notice that the first and last names are only loaded when the page is not a postback. That means that only the first time this page is loaded will the data will be loaded from the Profile datastore. After the first time, the data is stored in the page’s viewstate and no longer will have to be retrieved from the static Profile class. This is important to note because each time a profile property is accessed, a round trip to the membership database occurs. This is the reason using the Profile classes are often referred to as chatty with the database. Something to think about, and keep in mind when designing your application.

There are several good articles that go into more detail on using the profile provider. Scott Gu posts in his blog an excellent how to guide that steps you through creating basic Membership in a web application including customized Profile information. A good one in MSDN is Personalization and User Profiles in ASP.NET 2.0 by Dino Esposito. Another one of my favorites is Profiles in ASP.NET 2.0 by Scott Allen.

Why Do We Need This?

The questions comes up, why do we need an ObjectDataSource that encapsulates our Profile information? The answer is this. Even though ASP.NET does a wonderful job of giving us programmatic access to the Profile class it does not gives a simple way to view or update this data by binding it directly to any controls like gridview or detailsview. Joshua Flanagan wrote a very nice tool called ProfileView that you can see on his blog. Basically, he wrote an ASP.NET 2.0 server control that enables users to view and/or edit the Profile data. It does this using reflection at runtime to figure out what the profile information is, then it shows it.

The ObjectDataSource allows you at design time to make the presentation layer look exactly as you like. It also allows for viewing multiple members profiles at the same time. Take a look at the screen shot below to see what a gridview looks like using on ObjectDataSource generated using this technology. Also, you can play with it live right here.

At first glance, this is identical the screen developed in Part 2 of this series. If you look closer however (or at the picture to the right of the first one), you’ll notice that there are two new columns. First Name and Last Name. Both of these columns have data retrieved from the Membership Profile data provider we have been discussing. In the next section the details of what changes to the ObjectDataSource in the previous article have been made to allow this to happen. Something very important to note however, is that since the ObjectDataSource is basically a static class, the profile information in that ObjectDataSource will not automatically change when the web.config is changed (unlike Joshua Flanagan’s solution which will change).

Adding Profile Information to the ObjectDataSource

As was mentioned earlier, the ObjectDataSource developed here is 100% based on the one developed in Part II of this MSDN series, Implementation. The discussion here assumes all the previous code is understood and only explains the additions to support the Profile feature. All the code described here is what gets generated by the ObjectDataSource generator on Peter Kellner’s Blog (this tool is discussed in greater detail in the next major section of this article). In this section we go through the details of what gets added. In the next section it is shown how the steps to generating the source described here from an existing web.config file.

Changing Class Names

Since it’s possible the ObjectDataSource geneated here may be used in the same project as the one provided with Part 2 of this series, all the public names have been changed to avoid naming conflicts. For example, the class name MembershipUserODS has been renamed to MembershipUserAndProfileODS. The RoleData class has been renamed RoleDataForMP and the MemberhipUserWrapper class has been renamed MembershipUserWrapperForMP (MP standing for MembershipProfile).

The Insert Method

The method signature of Insert now contains all the names of the Profile properties. In addition to Membership.CreateUser being called, the Profile properties must be saves also with the Profile.Save() method. Below is the complete Insert method for an example set of profile properties (profile properties are stored in the web.config file and will likely be different for each asp.net web application).

[DataObjectMethod(DataObjectMethodType.Insert, true)]
public void Insert(string userName, bool isApproved,
    string comment, DateTime lastLockoutDate,
    DateTime creationDate,string email,
    DateTime lastActivityDate, string providerName,
    bool isLockedOut,DateTime lastLoginDate,
    bool isOnline, string passwordQuestion,
    DateTime lastPasswordChangedDate, string password,
    string passwordAnswer, string firstName,
    string lastName, bool advancedMode,
    string address_Street, string address_City,
    string address_State, string address_Zip
    )
{

    MembershipCreateStatus status;
    Membership.CreateUser(userName, password, email,
        passwordQuestion, passwordAnswer,
        isApproved, out status);

    if (status != MembershipCreateStatus.Success)
    {
     throw new ApplicationException(status.ToString());
    }

    MembershipUser mu = Membership.GetUser(userName);
    mu.Comment = comment;
    Membership.UpdateUser(mu);
    ProfileCommon pc =
     (ProfileCommon)ProfileBase.Create
        (mu.UserName, true);
    pc.FirstName = firstName;
    pc.LastName = lastName;
    pc.AdvancedMode = advancedMode;
    pc.Address.Street = address_Street;
    pc.Address.City = address_City;
    pc.Address.State = address_State;
    pc.Address.Zip = address_Zip;
    pc.Save();
}

Something also to take note of is the the variable names are constructed with an underscore because variable names with periods would not work. Notice in particular the properties that are nested such as address_state. This refers to the Profile property pc.Address.State.

The Delete Method

The delete method has no changes. This is because the membership class takes care of removing all profile information when Membership.DeleteUser() is invoked.

The Update Method

The Update method is changed. To the parameter list is added all the parameters representing properties. Then, in the update method itself the profile information is update after the Membership is updated. below is a portion of the code for this using the example properties.

ProfileCommon pc = (ProfileCommon)ProfileBase.
      Create(mu.UserName, true);
    pc.FirstName = firstName;
    pc.LastName = lastName;
    pc.AdvancedMode = advancedMode;
    pc.Address.Street = address_Street;
    pc.Address.City = address_City;
    pc.Address.State = address_State;
    pc.Address.Zip = address_Zip;
    pc.Save();

The Get (Select) Methods

Just like in Part 2 of this series, there are several Get Methods provided. No additional get methods are added, however now, because of the addition of the Profile properties, the Get Method’s return profile properties include Membership Properties as well as Profile properties. This is handled by first retrieving the Membership data with GetUser or GetUsers methods, then adding the additional properties from the profile to the Generic list which will get returned. The critical section of code that does this is next.

MembershipUserCollection muc = Membership.GetAllUsers();
foreach (MembershipUser mu in muc)
{
 if ((returnAllApprovedUsers==true && mu.IsApproved==true) ||
 (returnAllNotApprovedUsers==true && mu.IsApproved==false))
 {
    MembershipUserWrapperForMP md =
      new MembershipUserWrapperForMP(mu);
    ProfileCommon pc = (ProfileCommon)ProfileBase.Create
      (mu.UserName, true);
    md.FirstName = pc.FirstName;
    md.LastName = pc.LastName;
    md.AdvancedMode = pc.AdvancedMode;
    md.Address_Street = pc.Address.Street;
    md.Address_City = pc.Address.City;
    md.Address_State = pc.Address.State;
    md.Address_Zip = pc.Address.Zip;
    memberList.Add(md);
 }
}

Sorting Support

Sorting the ObjectDataSource’s columns is also supported. Just as in Membership Part 2, this is supported using anonymous delegates. Basically, a comparater method is created with an anonymous delegate that takes two parameters. The left and right hand side of a sort operation. Then, using this comparater, the generic List is sorted before being returned to the caller. This very clever construct was inspired by Ted Neward at a Code Camp in Portland.

Just like the MembershipUser properties, Profile properties are handled the same way so that those values can be sorted in a GridView by clicking on the column headers. Below is the creation of one comparater method.

switch (sortDataBase)
{
  case "FirstName":
    comparison = new
      Comparison<membershipuserwrapperformp>(
       delegate(MembershipUserWrapperForMP lhs,
            MembershipUserWrapperForMP rhs)
       {
           return lhs.FirstName.CompareTo(
              rhs.FirstName);
       }
     );
    break;</membershipuserwrapperformp>

The Class associated with the Generic List

The final piece of code that has to be extended is the Class that is returned from the Get methods. That is the generic list which is declared as follows.

 protected void Page_Load(object sender, EventArgs e)
{
  // Only allow for profile update when a user is logged in
  MembershipUser mu = Membership.GetUser();
  if (mu == null)
  {
    ButtonUpdate.Enabled = false;
  }
  else
  {
    if (!IsPostBack)
    {
      TextBoxFirstName.Text = Profile.FirstName;
      TextBoxLastName.Text = Profile.LastName;
    }
  }
}

One Final Trick on Using the ObjectDataSource

ObjectDataSource’s are great for using with databound ASP.NET’s controls such as GridView and DetailsView. They are wired such that the get methods, update, delete and insert line up perfectly with what those controls are looking for. However, the ODS’s can be used directly without having a presentation style control associated with them. For example, the Insert method associated with adding a new member in the included code from the asp.net page MembershipWithProfile.aspx uses the ObjectDataSource to insert even though it is not bound to any control on the page. The data it is entering is coming from TextBox’s in a table. Below is the Insert code used. Notice how straight forward it is to use compared do creating an inserter and doing all the ADO without this class.

protected void ButtonNewUser_Click(object sender, EventArgs e)
{

    MembershipUtilities.MembershipUserAndProfileODS
      membershipUserAndProfileODS =
        new MembershipUserAndProfileODS();

    membershipUserAndProfileODS.Insert(
        TextBoxUserName.Text,
        CheckboxApproval.Checked,
        string.Empty,
        DateTime.Now,
        DateTime.Now,
        TextBoxEmail.Text,
        DateTime.Now,
        string.Empty,
        false,
        DateTime.Now,
        false,
        TextBoxPasswordQuestion.Text,
        DateTime.Now,
        TextBoxPassword.Text,
        TextBoxPasswordAnswer.Text,
        TextBoxFirstName.Text,
        TextBoxLastName.Text,
        false,
        string.Empty,
        string.Empty,
        string.Empty,
        string.Empty);

    GridViewMemberUser.DataBind();
    TextBoxUserName.Text = string.Empty;
    TextBoxFirstName.Text = string.Empty;
    TextBoxLastName.Text = string.Empty;
    TextBoxPassword.Text = string.Empty;
    TextBoxEmail.Text = string.Empty;
    TextBoxPasswordAnswer.Text = string.Empty;
    TextBoxPasswordQuestion.Text = string.Empty;
    CheckboxApproval.Checked = false;
}

Because this is an actual class with properties, using the ObjectDataSource class is type safe. For example, in the code below, the user may want to count how many zipcodes in the membership database that begin with 9. Here is the code to do it. Notice how Address_Zip is used in a type safe way.

protected void ButtonZipCount_Click
    (object sender, EventArgs e)
{
    MembershipUtilities.MembershipUserAndProfileODS
        membershipUserAndProfileODS =
        new MembershipUserAndProfileODS();

    List<membershipuserwrapperformp> li =
        membershipUserAndProfileODS.GetMembers
        (string.Empty);

    int count = 0;
    foreach (MembershipUserWrapperForMP mu in li)
    {
        if (mu.Address_Zip.StartsWith(&quot;9&quot;))
        {
            count++;
        }
    }
}</membershipuserwrapperformp>

Using the Profile Generating Website

All the changes listed in the previous section could be done by hand, however this would be very tedious. To make this process much easier, a code generator has been developed which takes as input the applications web.config file’s <System.Web> section. The idea is to cut this out of the web.config file and paste it into the web page which will generate the code for you. Below is a screen show of what the web page looks like. When you get to this page, you must first click on the button in the right column labeled "Click Here to Begin".

Here is the URL: http://painfreeods.peterkellner.net/

The XML which is pasted into the multi line orange textbox is as follows (you should paste your own in here).

<system  .web>
  <profile defaultprovider="SqlProfileProvider">
    <providers>
      <remove name="AspNetSqlProfileProvider" />
      <add name="SqlProfileProvider" connectionstringname="LocalSqlServer" type="System.Web.Profile.SqlProfileProvider" />
    </providers>
    <properties>
      <add name="FirstName" type="string" />
      <add name="LastName" type="string" />
      <add name="AdvancedMode" type="bool" />
      <group name="Address">
        <add name="Street" type="string" />
        <add name="City" type="string" />
        <add name="State" type="string" />
        <add name="Zip" type="string" />
      </group>    </properties>  </profile>
</system>

Now, if the "Show Generated C#" button is pressed, the complete ObjectDataSource will be created. This code can then be cut and pasted into the App_Code directory of the web project. Here is what the screen looks like.

There are some limitations to this code generation technology. First is that there can only be one level of nesting. That is, there can be no groups of groups. Just one level of grouping is allowed as is shown here. It is OK to have multiple groups, just not nested. Another limitation is the type associated with the name must be a C# type. That is, string, bool,DateTime,etc. The final limitation (known about) is that it can not handle Array or Collection type properties. All properties must be single valued.

At this point, error checking is minimal so if the limitations are exceeded, something will likely come out but it may not be what was desired.

Build A Simple Web Page

Now that the C# class has been generated, the next steps are very straight forward. For those who have not built a GridView based on an ObjectDataSource, here is a pictorial step by step of the 9 things needed to do to have a very simple gridview control in under 5 minutes.

The code in the associated source to this article has a web apge ( MembershipWithProfile.aspx) which is very similar to what is done here.

Conclusions

Profiles are a very powerful way to store information about Membership. It’s powerful in that with very little coding, lots of additional information about logged in users is available. With this tool, there is now a better way to organize this information and maintain it. Briefly mentioned earlier were the performance implications of using Profile information. It is important to understand what his happening under the covers when this technology is used. As long there is an understanding of what is happening and it is acceptable in the web application being developed, this is a wonderful technology.

Finally, as a plug to the technology that was used in this free ObjectDataSource creator, the Pain Free ObjectDataSource Creator, available through subscription on this blog, lets the developer generate very flexible ObjectDataSource’s to access database information in SqlServer, MySql and Oracle. Unlike the Profile ODS generator in this article, the ODS generator for databases gives you a large amount of flexibility. An infinite number of getter methods, updaters and inserters can be defined. It works with views, and also stored procedures. Any questions on the Pain Free ODS Generator, click here.

Thanks for reading, and best of luck with your coding projects.

Applies to:

Microsoft ASP.NET 2.0

Microsoft Visual Studio 2005

Microsoft Internet Information Services

 Run Live Demonstration Of AJAX Technology

Click Here for Source Code Associated With This Article 

Contents

Introduction
What is AJAX and Atlas
Background
The AJAX Enhanced Version
Technologies Used in AJAX Enhanced Version
Steps Involved in Building (or upgrading) to AJAX using Atlas
Using UpdatePanel ASP.NET Tag
What is Really Happening
Enhancing the TextBox for User Search
Conclusions 

Introduction

This article extends one of the web pages developed in Part II of this series using Microsoft’s implementation of AJAX called Atlas. It utilized two techniques for reducing web server traffic to the browser to enhance the users web experience. The first technique uses the UpdatePanel tags to limit the refreshed area of the web page to limited areas and the second has to do with implementing some javascript using Atlas techniques so that the web page is updated on every key stroke in a textbox. A user list is displayed based on what is actively typed into this textbox. After reading this article the developer will be able to implement AJAX (Microsoft’s implementation Atlas) in their own application.

What is AJAX and Atlas

AJAX is an acronym for Asynchronous JavaScript And XML. It is a technique for making interactive web applications more responsive. It does this by exchanging small amounts of information between the web server and the web client, thereby reducing the amount of traffic to the web client and making the application more responsive. Without AJAX, each time a page is refreshed (or a postback in generated) the complete page must be retransmitted to the users web browser. This is somewhat mitigated by the local cache on the web browser, but still overkill since most of the information on a postback to a web page does not change.

Atlas is Microsoft’s implantation of AJAX. It is designed to make it relatively easy for software engineer, already skilled in ASP.NET 2.0 to take advantage of AJAX. Though Atlas has huge capabilities (which, by the way come with a huge learning curve), it is very easy to implement the basics of AJAX and significantly improve the user experience of a web site designed with ASP.NET 2.0 as well be shown in this article.

Background

Managing membership and roles for ASP.NET 2.0 using ObjectDataSource technology was developed in a previous article published by this author in MSDN ( http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnaspp/html/ASP2memroleman.asp ). This article stepped through the inner workings of an ObjectDataSource that allowed for the easy creation of gridviews, dataviews, or any other databound control. It also presented a best practices solution in the form of a ASP.NET 2.0 web page (aspx file). The solution allowed for adding, modifying and deleting members, adding and deleting roles, as well as assigning users to roles. The solution is functionally similar to what comes with Visual Studio 2005 under the menu item "Website / ASP.NET Configuration". The major benefit is that this solution works 100% with IIS 5.1 and 6.0 and gives the software engineer complete customization control of what is presented to the user. It would normally be set to administrator access only. Below is a screen shot of this application previously developed.

This application shown above has no AJAX technology in it. This means that every interaction you have with the web form requires a full page refresh of html from the web server. In this case, a picture is not worth very many words, but a URL will certainly make the point. Go to the URL: http://livedemos.peterkellner.net/AJAXDemo/Default.aspx and play with the web site. Feel completely free to search on this data, add new users, add roles, assign and unassign roles as you please noticing at the time how the page reacts to changes. In particular, note the Search button on top for finding users. This search is a little different than you would normally expect. Instead of looking for exact matches, it effectively finds usernames that begin with what you have typed in the textbox when you press the search button. In the next section, the AJAX enhanced version, the search button is gone and as the username is typed into the textbox, the list of usernames will be automatically updated. This could have been done here also, however it would have caused a complete refresh of the page on every keystroke. Not only would the performance have been unacceptable, it would also have been unusable with all the flashing while typing. This is why in non-AJAX applications, there is almost always a button to press when data is finished being entered.

While you are running the demonstration program, notice at the top of the page there is a link that takes you to the same application without AJAX. Notice that in this application, there is a button for search. Notice also when you check and uncheck the checkboxes to display Manage Roles or Create New Users, those sections turn on and off with a lot of screen refreshing. Also notice the difference when you edit users and assign or unassign roles.

The AJAX Enhanced Version

Without actually running the web application, the only visual change the user can see in the AJAX enhanced version of this application is that there is no search button above the user list. This is because with AJAX, as the user types in the search criteria, the list of users is automatically restricted to the search criteria defined by users that begin with what is typed. Notice in the screen shot below, ch is entered into the username textbox and just the usernames beginning with ch automatically appear.

Technologies Used in AJAX Enhanced Version

Obviously, Microsoft’s Atlas is the primary technology used to implement AJAX. Atlas has lots of functionality and capability, however in this article (and the code associated with the AJAX enhanced Membership Editor), there is just a small part of Atlas being used. Actually, there are only two technologies going on. One has to do with the updates on the screen not requiring complete html refreshes between postbacks, and the other has to do with extending the functionality of the TextBox control the user enters the name for search. Because the default TextBox has no event associated with characters changing (it only has an event which generates a postback for TextChanged) the TextBox has to be enhanced to deal with the javascript function OnTextChanged.

Steps Involved in Building (or upgrading) to AJAX using Atlas

In order to Atlas enable an application you need to make several changes to your project. I won’t go through all the details, however, the basics are you need to copy in the Atlas script library, modify your web.config, add the atlas dll to your project and finally, add some initializing tags in your aspx pages. The other way to begin working with Atlas (and is it was done to convert the project associated with this article) is first download the new Atlas template from Microsoft’s Atlas web site. Then, create a new web project using the newly installed Atlas template. Next, rename the default.aspx file in case you have your own, then copy in all your existing libraries and pages. Finally, add your sections to the Atlas enabled web.config file and make sure everything works as before with no Atlas functionality. The final step is to look at the original default.aspx file and copy the Atlas constructs into the headers of an existing page you want to add AJAX capabilities.

It is recommended not to put Atlas in your master page because there are undoubtedly pages that do not need AJAX capability. It is better to put that capability in only the pages you need to keep things simple.

Using UpdatePanel ASP.NET Tag

Below is the actual UpdatePanel asp.net control surrounding the checkboxes that let you turn on and off the Role Management, and the Create of New User section. It’s the two checkboxes half way down the web screen.

<atlas :UpdatePanel ID="UpdatePanelCheckBoxes" runat="server">
 <contenttemplate>
  <table>
   <tr>
    <td align="left">
        <asp :CheckBox ID="CheckBoxManageRoles" Text="Manage Roles"
          runat="server" AutoPostBack="True" Checked="True" />
    </td>
    <td align="right">
        <asp :CheckBox ID="CheckBoxAddUser" Text="Create New Users"
         runat="server" AutoPostBack="True" Checked="True" />
    </td>
   </tr>
  </table>
 </contenttemplate>
</atlas>

The UpdatePanel control is the control that will most likely be used the most. By surrounding parts of the web page that will change on the postback, this causes the affect of letting this section update with out actually a screen refresh. Essentially, what Atlas does on a page that is Atlas enabled, is it lets all the normal asp.net page lifecycle events process normally (including the Page_Init method) but instead of redisplaying all the HTML in the Page_Render method, it knows to only update code inside the UpdatePanels defined on the web page. In reality what is happening is Atlas is simulating a postback instead of doing a real one.

Something that must be set also is in the ScriptManager tag, for this to actually work, the EnablePartialRendering must be set to true as shown below. If it is not set, then the page behaves as if the UpdatePanel tags are not there.

<atlas :ScriptManager ID="ScripManager" runat="server"
   EnablePartialRendering="true">
</atlas>

The final thing to do is to surround all the areas on the aspx page with these UpdatePanel tags. Once this is done, VS2005 does a nice job of showing the UpdatePanel areas. The screen shot below shows the actual screen shot of the page used to manage members. Notice all the UpdatePanel tags displayed above the regions. Clicking on the image will display a large one which is much easier to see the details.

Trigger tags go hand in hand with the UpdatePanel control. Essentially, you can nest trigger controls in the UpdatePanel control and that will specify when the UpdatePanel will actually be posted back. You can specify triggers in two ways. The first way is on some control event such as the EventName "Click" on the button control. The other way is on some control value changing. with that, you would specify the controlID and the property name. There are no examples of triggers in the article download. The code below is just an example of typical code.

<atlas :UpdatePanel ID="Panel1" runat="server">
 <contenttemplate>
  <asp :TextBox ID="TextBox1" runat="server"></asp>
  <asp :Button ID="Button1" runat="server"></asp>
 </contenttemplate>
 <triggers>
  <atlas :ControlEventTrigger ControlID="Button1" EventName="Click" />
  <atlas :ControlValueTrigger ControlID="TextBox1" PropertyName="Text"   />
 </triggers>
</atlas>

What is Really Happening

To understand what is really happening with these UpdatePanel tags, it is helpful to look at the source generated for the web page. Essentially what is happening is that for every control on your web page that is surrounded by the UpdatePanel tags, javascript is created which forces a postback on every click. For example, just looking at the checkboxAddUser control, the following is what is generated.

<td align="right">
 <label for="CheckBoxAddUser">Create New Users</label>
   <input id="CheckBoxAddUser"
   type="checkbox" name="CheckBoxAddUser"
   checked="checked" onclick=
   "javascript:setTimeout
   ('__doPostBack(\'CheckBoxAddUser\',\'\')', 0)" />
</td>

This is in addition to all the javascript references that include lots of other javascripts. The bottom line here is that if you include Atlas in your web pages, the actual payload size delivered to your web page in bytes will be significantly larger on the first download then it would be without Atlas. Subsequent requests are of course much smaller because, depending on how you design your page, only small amounts of data need to be returned on each future postback.

Enhancing the TextBox for User Search

The textbox search functionality is a little more tricky. It involves adding javascript which reacts to keystrokes changes. The reason this is necessary is because there is not event in the TextBox control that responds to keyboard clicks. There is only an event that reacts to text changes which is not good enough for our needs. In this application, I am using javascript from The Atlas Notes Blog by Garbin

The steps necessary to make this work are as follows:

Add the TextChangedBehavior.js to the ScriptLibrary folder

Add just below the <form> tag of your aspx page a line that includes the new javascript

<atlas :ScriptManager ID="sm" runat="server"
     EnablePartialRendering="true">
 <scripts>
  <atlas :ScriptReference
     Path="ScriptLibrary/TextChangedBehavior.js" />
 </scripts>
</atlas>

Add a small javascript code piece to your web page that your TextBox control will reference

<script type="text/javascript">
  function onTextChange() {
    __doPostBack('GridViewMemberUser','') ;
        }
</script>

And, finally add another xml-script to the bottom of your web page that declaratively tells the Atlas processor to add this new javascript capability to the TextBoxSearchUser Control. This essentially maps the onclick event of the TextBoxSearchUser to the onTextChange javascript. The timeout is very nice because it allows for typing without causing postbacks until the typer stops typing for that many milliseconds.

<script type="text/xml-script">
 <page>
  <components>
   <textbox id="TextBoxSearchUser">
    <behaviors>
     <textchangedbehavior timeout="100"
        changed="onTextChange" />
    </behaviors>
   </textbox>
  </components>
 </page>
</script>

Conclusions

AJAX, though in concept is not new, is one of the most exciting new technologies to hit the Web for quite some time. The tool kits now available, such as Microsoft’s Atlas which is described here and included with the demonstration download, makes adding AJAX functionality to existing ASP.NET 2.0 applications very straight forward. In this article, I’ve discussed the mechanics of adding AJAX functionality but have not addressed the impact to web servers, cross browser functionality or web design. Those things must all be considered before including AJAX technology in an existing web application. Overall however, AJAX, and Microsoft’s implementation ATLAS, are wonderful things.

Click Here for Source Code Associated With This Article

Applies to:

• Microsoft ASP.NET 2.0
• Microsoft Visual Studio 2005
• Microsoft Internet Information Services

Link To Part 1: Security and Configuration

Contents

Introduction
Technologies Used
The Application and Project
The ObjectDataSource in Detail
The Return Value of the Select Method (Type Collection)
The Select Method Itself
The Custom Sort Criteria
ObjectDataSource In GridView (Data Control)
Conclusion

Introduction

Figure 1. Membership Editor

With the release of Microsoft Visual Studio 2005, there is no "out of the box" solution for maintaining the Membership and Role databases in Microsoft IIS. This is a problem when you move your application from development to a production IIS server. The utility that Microsoft provides, ASP.NET Web Configuration, can be run only in a development, non-production environment. This article and its associated code solve this by implementing a three-tier solution to Member and Role management while using standard Microsoft ASP.NET tools. This means that it will run in any ASP.NET 2.0 environment, including IIS. The solution is flexible and very easy to add to any existing ASP.NET 2.0 website project.

The tiers of this solution are defined as follows. The first tier, the ASP.NET page (also known as the presentation layer), interfaces with two business objects through the object data source. These business objects function as the middle tier, and they are wrappers for members and roles. The third tier, or back end, consists of the Membership and Role Manager APIs provided by ASP.NET. The middle tier objects can easily be dropped into any ASP.NET 2.0 project and used directly, with almost no changes.

This article explains in depth the implementation of the middle tier—that is, the data objects, as well as the ObjectDataSource that is associated with them. It then explains how to use these objects in an ASP.NET Web project that uses Microsoft SQL Server Express 2005, which comes bundled with Visual Studio 2005. However, the Membership API provided by Microsoft uses their provider technology; therefore, the solution presented here is database independent. Membership and role information could just as easily come from LDAP, SQL Server, or Oracle.

Technologies Used

The ObjectDataSource

There are two ObjectDataSource instances defined. One is for Membership Data (User Names, Creation Date, Approval, and so on), and the other is for Roles (Administrator, Friends, and so on). Both of these data sources are completely populated with all of the data access methods—that is, they both have Member functions that perform inserts, updates, deletes, and selects. Both ObjectDataSource instances return a Generic List type, which means that in the GridView, the column names are automatically set to the property value names of the ObjectDataSource. In addition, custom sorting is implemented so that users can click the column headers in the GridView in order to sort the data forwards or backwards, as desired.

SQL Server Express 2005 and Web.Config

The data provider source for the Membership and Role databases is SQL Server Express 2005. The appropriate entries are set in the web.config file in order to make this happen. A short discussion is given later in this article of how to set up a new project from scratch. The connection string for SQL Server Express 2005 is not mentioned in the web.config file, because it is already defined in the Machine.Config file that is included as a default part of the Microsoft .NET 2.0 Framework.

IIS (5.1 and 6.0) Compatible

The Web server can be either version 5.1 or 6.0. In order to do any testing of multiple users logged in to your Web app, you must use IIS. The built-in development Web server does not correctly maintain state of the different users who are logged in. Although the Asp.net Web config tool could be made to work with IIS, the additional security work necessary in order to enable this was not done.

The GridView Control

The GridView is used to present the data for both membership and roles. As mentioned earlier, because of the use of a Generic type for the ObjectDataSource, the column names of the GridView are automatically named after the property values of the ObjectDataSource. Without the use of Generics, the column names revert to meaningless default values and must each be edited by hand.

The Application and Project

The project necessary in order to run this utility is very simple and self-contained. The project files, which are available for download, contain a full working example. Because there is no direct database access to the users and roles, all that is needed is to grab the three data objects (MembershipDataObject.cs, MembershipUserSortable.cs and RoleDataObject.cs: see Figure 2).

Figure 2. Membership Editor project

In the SamplePages folder there are several other samples that demonstrate the use of the previously mentioned modules. As one example, Membership.aspx is the example shown in Figure 1. It can be used for selecting, updating, inserting, and deleting Members and Roles, as well as for assigning roles to members.

With a working ASP.NET 2.0 application that already has a working membership module, these pages should need no external configuration beyond what has already been done. These files can be copied directly into a project and they will just work.

If this is the first implementation of Membership and Role Management in an application, the process to follow to create a solution using these objects is as follows:

1. Using Visual Studio 2005, create a new Web project of the type ASP.NET Web Site.
2. Click Website / ASP.NET Configuration on the menu.
3. Follow the wizard steps (1 to 7) to create some sample users and roles. This will effectively create a valid web.config file in the current project that has enough information to have Member Management up and running. By default, it will use SQL Server Express 2005 in its default configuration.
4. Include the three .cs files in the project, and then include the sample .aspx pages as samples.

The ObjectDataSource in Detail

The ObjectDataSource technology enables the creation of a datasource that behaves very similarly to the SqlDataSource—that is, it exposes interfaces that allow for selecting, updating, inserting, and deleting records (or record-like objects) from a persistent data store (such as a database). The next several sections of this article will discuss the object (or class file) that the ObjectDataSource uses to manipulate membership. Its name in the project is MembershipUserODS.cs.

The Class (MembershipUserODS)

Because the data is retrieved from the Microsoft Membership API, an ObjectDataSource is used to solve the problem. The first step in doing this is to create a stand-alone class that wraps MembershipUser so that it can be associated with the ObjectDataSource. The example below shows a typical set of methods that need to be implemented, and the next several sections of this article will discuss the implementation of each member function. Many of the details are left out of the article, but they are included in the source code provided with this article.

[DataObject(true)
public class MembershipUserWrapper {
  [DataObjectMethod(DataObjectMethodType.Select, true)]
  static public Collection<membershipuserwrapper> GetMembers(string
       sortData) {
    return GetMembers(true, true, null, sortData);
  }

  [DataObjectMethod(DataObjectMethodType.Insert, true)]
  static public void Insert(string UserName, bool isApproved,
string comment, DateTime lastLockoutDate, ...) {
  }

  [DataObjectMethod(DataObjectMethodType.Delete, true)]
  static public void Delete(object UserName, string Original_UserName){
    Membership.DeleteUser(Original_UserName, true);
  }

  [DataObjectMethod(DataObjectMethodType.Update, true)]
  static public void Update(string original_UserName,string email,...){
  }
}
</membershipuserwrapper>

The Class Declaration

The class declaration shown above is special because of the attribute [(DataObject(true)]. This attribute tells the the Visual Studio 2005 ObjectDataSource Creation Wizard to look only for members with this special attribute when searching for DataObjects in the data class. See the example in the section showing where this class is assigned to a GridView component.

The Insert Method

The details of each section involve a very straightforward use of the Membership API provided by Microsoft. For example, here is what might be a typical Insert method in more detail.

[DataObjectMethod(DataObjectMethodType.Insert,true)]
static public void Insert(string userName, string password,)
{
   MembershipCreateStatus status;
      Membership.CreateUser(userName, password,);
}

This class Insert is polymorphic, which means there can be multiple Insert methods used for different purposes. For example, it may be necessary to dynamically decide whether a created user should be approved depending on the circumstances. For example, a new user created in an admin screen may want to create users defaulted to approved, whereas a user register screen might default to not approved. To do this, another Insert method is needed, with an additional parameter. Here is what an Insert method that would achieve this goal might look like.

[DataObjectMethod(DataObjectMethodType.Insert,false)]
static public void Insert(string userName, string password, bool isApproved)
{
MembershipCreateStatus status;
   Membership.CreateUser(UserName, password,
      isApproved, out status);
}

As with the other methods listed here, the examples shown are not what will actually be found in the accompanying source. The examples here are meant to be illustrations of typical uses. More complete and commented uses are included in the source.

The Update Method

The Update method is a very straightforward implementation of the Membership API. Just like the Insert method, there can be multiple implementations of Update. Only one implementation is shown here. In the code available for download, there are more polymorphic implementations of Update, including one that just sets the IsApproved property (shown in the following example).

[DataObjectMethod(DataObjectMethodType.Update,false)]
static public void Update(string UserName,bool isApproved)
{
   bool dirtyFlag = false;
   MembershipUser mu = Membership.GetUser(UserName);
   if (mu.isApproved != isApproved)
   {
      dirtyFlag = true;
      mu.IsApproved = isApproved;
   }
   if (dirtyFlag == true)
   {
      Membership.UpdateUser(mu);
   }
}

The Delete Method

The Delete method is the simplest, and it takes one parameters, UserName.

<h2>The Delete Method</h2>
static public void Delete(string UserName)
{
   Membership.DeleteUser(UserName,true);
}

The Select Method with a Sort Attribute

The Select method—GetMembers, in this case—has multiple components, each of them worthy of discussion. First, what it returns is discussed, and then the actual method itself, and finally, how it sorts what it returns.

The Return Value of the Select Method (Type Collection)

The return value of the Select method (which also is referred to as Get) is a Generic Collection class. Generics are used because the ObjectDataSource ultimately associated with the class uses reflection to determine the column names and types. These names and types are associated with each row of data that is returned. This is the same way that a SqlDataSource uses the database metadata of a table or stored procedure to determine the column names of each row. Since the return type of the Select method is MembershipUserWrapper, which inherits from MembershipUser, most of the properties of this class are the same properties that are associated with MembershipUser. Those properties include:

• ProviderUserKey
• UserName
• LastLockoutDate
• CreationDate
• PasswordQuestion
• LastActivityDate
• ProviderName
• IsLockedOut
• Email
• LastLoginDate
• IsOnline
• LastPasswordChangedDate
• Comment

Jumping ahead of ourselves a little, one very nice feature of property values is that they can be Read-only (no set method), Write-only (no read method), and of course, Read/Write. The ObjectDataSource Wizard recognizes this and builds the appropriate parameters so that when the datacontrol is rendered (using the ObjectDataSource), just the fields that are updatable (read/write) are enabled for editing. This means that you can not change the UserName property, for example. If this does not make sense now, it will later, when we discuss the ObjectDataSource and the data components in more detail.

The Select Method Itself

Just like Insert and Update, the Select method is polymorphic. There can be as many different Select methods as there are different scenarios. For example, it may be desiable to use the Select method to select users based on whether they are approved, not approved, or both. Typically, there is one Get method that has the most possible parameters associated with it, and the other Get methods call it. In our case, there are three Get methods: one to retrieve all records, one to retrieve based on approval, and one to retrieve an individual record based on a select string. In the following example, the method that returns all users is being called. By setting both Booleans to true, all users will be returned.

[DataObjectMethod(DataObjectMethodType.Select, true)]
static public List<membershipdata> GetMembers(string sortData)
{
   return GetMembers(true,true,null,null);
}
</membershipdata>

The next example shows a more detailed Get method. This example shows only the beginning of the method. The details of the method not shown include finishing the property assignments, filtering for approval status and rejecting the records not meeting the criteria, and applying the sort criteria. Following this example is more discussion about the sort criteria. (Note that calling GetAllUsers on a database with more than a few hundred users [the low hundreds] is quickly going to become an expensive operation.)

[DataObjectMethod(DataObjectMethodType.Select, true)]
static public List<membershipdata> GetMembers(bool AllApprUsers,
    bool AllNotApprUsers, string UserToFind, string sortData)
{
   List</membershipdata><membershipdata> memberList = new List</membershipdata><membershipdata>();
   MembershipUserCollection muc = Membership.GetAllUsers();
   foreach (MembershipUser mu in muc)
   {
      MembershipData md = new MembershipData();
      md.Comment = mu.Comment;
      md.CreationDate = mu.CreationDate;
</membershipdata>

The Custom Sort Criteria

Notice that, in the preceding code, a parameter string named sortData is passed into GetMembers. If, in the ObjectDataSource declaration, a SortParameterName is specified as one of its attributes, this parameter will be passed automatically to all Select methods. Its value will be the name specified by the attribute SortExpression in the column of the datacontrol. In our case, the datacontrol is the GridView.

The Comparer method is invoked based on the parameter sortName coming into the GetMembers method. Since these ASP.NET Web pages are stateless, we have to assume that the direction of the current sort (either forward or backwards) is stored in the viewstate. Each call reverses the direction of the previous call. That is, it toggles between forward sort and reverse sort as the user clicks the column header.

Assuming that a GridView is used, the parameter that gets passed into GetMembers(sortData) has in it the data from the SortExpression attribute of the GridView column. If a request for sorting backwards is being made, the word "DESC" is appended to the end of the sort string. So, for example, the first time the user clicks on the column Email, the sortData passed into GetMembers is "Email." The second time the user clicks on that column, the parameter sortData becomes "Email DESC," then "Email," then "Email DESC," and so on. As a special note, the first time the page is loaded, the sortData parameter is passed in as a zero-length string (not null). Below is the guts of the GetMembers method that retrieves and sorts the data so that it is returned in the correct order.

[DataObjectMethod(DataObjectMethodType.Select, true)]
static public List<membershipdata> GetMembers(string sortData)
{
  List</membershipdata><membershipdata> memberList = new List</membershipdata><membershipdata>();
  MembershipUserCollection muc = Membership.GetAllUsers();
  List<membershipuser> memberList = new List</membershipuser><membershipuser>(muc);

  foreach (MembershipUser mu in muc)
  {
    MembershipData md = new MembershipData(mu);
    memberList.Add(md);
  }

  ... Code that implements Comparison

  � memberList.Sort(comparison);

  return memberList;
}
</membershipuser></membershipdata>

In the next section, when this is incorporated into a GridView, it will become more clear.

The ObjectDataSource Declaration

The easiest way to declare an ObjectDataSource is to drag and drop one from the datacontrols on the toolbar, after first creating an empty ASP.NET page with the Visual Studio 2005 wizard. After creating the ObjectDataSource, a little tag in the upper-right corner of the newly created ObjectDataSource can be grabbed; then, clicking Configure Data Source opens a wizard saying "Configure Data Source—ObjectDataSource1" (see Figure 3).

Figure 3. Configuring ObjectDataSource

At this point, two classes that are available for associating with an ObjectDataSource will be seen. MembershipUserODS is the primary subject of this article. RoleDataObject is basically the same thing, but it encapsulates Membership Roles. Also, remember that what is shown here are just the objects that are declared with the special class attribute [DataObject(true)] that was described in "The Class Definition."

After choosing MembershipUserODS, a dialog box with four tabs appears. The methods to be called from the MembershipUserODS class will be defined on these tabs. Methods for Select, Update, Insert, and Delete will be associated with member functions in the MembershipUserODS. In many cases, there will be multiple methods available in the class for each of these. The appropriate one must be chosen, based on the data scenario desired. All four tabs are shown in Figure 4. By default, the members that are marked with the special attribute [DataObjectMethod(DataObjectMethodType.Select, false)] will be populated on the tabs. Of course, however, this particular attribute is the default for Select. Changing the expression DataObjectMethodType.Select to DataObjectMethodType.Insert, DataObjectMethodType.Update, and DataObjectMethodType.Delete will make the defaults appropriate for the different tabs. The second parameter, a Boolean, signifies that this method (remembering that it may be defined polymorphically) is the default method, and that it should be used in the tab control.

The Select Method

As mentioned earlier, in the section describing the MembershipUserODS class, the GetMembers function returns a Generic Collection class. This enables the ObjectDataSourceMembershipUser control defined here to use reflection and ascertain the calling parameters associated with this GetMembers call. In this case, the parameters used to call GetMembers are returnAllApprovedUsers, returnAllNotApprovedUsers, userNameToFind, and sortData. Based on this, the actual definition of the new ObjectDataSource will be as follows.

Figure 4. Assigning the Select method

<asp :ObjectDataSource ID="ObjectDataSourceMembershipUser"runat="server"
    SelectMethod="GetMembers"UpdateMethod="GetMembers"
    SortParameterName="SortData"
    TypeName="MembershipUtilities.MembershipDataObject"
    DeleteMethod="Delete" InsertMethod="Insert">
    <insertparameters>
        <asp   arameter Name="userName" Type="String" />
        <asp   arameter Name="password" Type="String" />
        <asp   arameter Name="isApproved" Type="Boolean" />
    </insertparameters>
</asp>

The Insert Method

The Insert method, in this case, is assigned to the member function Insert(). Notice that this method is called with only two parameters: UserName and Password (see Figure 5). The number of parameters must equal the number of parameters declared in the ObjectDataSource. The parameter declaration from the ObjectDataSource is shown below. There is a second Insert Member function defined that adds a third parameter: approvalStatus. If the functionality of this ObjectDataSource is to include inserting while setting the approvalStatus, then the other insert method should be chosen from the drop-down list. That would cause the following InsertParameters to be inserted into your .aspx page. If the one with two parameters is chosen, the block would not include the asp:Parameter with the name isApproved in it. Again, keep in mind that this example may not agree with the source code enclosed, and that it is here only as an example. The source enclosed is much more complete.

Figure 5. Assigning the Insert method

<asp :ObjectDataSource ID="ObjectDataSourceMembershipUser"runat="server"
    SelectMethod="GetMembers"UpdateMethod="GetMembers"
    SortParameterName="SortData"
    TypeName="MembershipUtilities.MembershipDataObject"
    DeleteMethod="Delete" InsertMethod="Insert">
    <insertparameters>
        <asp   arameter Name="userName" Type="String" />
        <asp   arameter Name="password" Type="String" />
        <asp   arameter Name="isApproved" Type="Boolean" />
    </insertparameters>
    ...
</asp>

Also, keep in mind that using an Insert method with minimal parameters will require a default password to be set in the method. In a production system, this would be a bad idea. See the attached source code for a better example of how to handle inserts. Specifically, see the page Membership.aspx for this functionality.

The Update Method

The Update method, in this case, is assigned to the member function Update(). Notice that this method is called with multiple parameters: UserName, Email, isApproved, and Comment (see Figure 6). In addition, there is another Update method that has all the updatable parameters. This is useful for creating a control that has the most possible update capabilities. Just like Insert, the appropriate Update method is chosen for this ObjectDataSource. When the wizard is finished, it will automatically create UpdateParameters, as shown below.

Figure 6. Assigning the Update method

<asp:ObjectDataSource ID="ObjectDataSourceMembershipUser"runat="server"
    SelectMethod="GetMembers" InsertMethod="Insert"
    SortParameterName="SortData"
    TypeName="MembershipUtilities.MembershipUserODS"
    UpdateMethod="Update" DeleteMethod="Delete">
    <updateparameters>
        <asp   arameter Name="Original_UserName" />
        <asp   arameter Name="email" Type="String" />
        <asp   arameter Name="isApproved" Type="Boolean" />
        <asp   arameter Name="comment" Type="String" />
    </updateparameters>
    ...
    ...

The Delete Method

The Delete method, in this case, is assigned to the member function Delete(). There is, of course, only one Delete method necessary (see Figure 7). Below is the declaration of the ObjectDataSource that supports this Delete method.

Figure 7. Assigning the Delete method

<asp:ObjectDataSource ID="ObjectDataSource1" runat="server"
    SelectMethod="GetMembers" InsertMethod="Insert"
    SortParameterName="SortData"
    TypeName="MembershipUtilities.MembershipUserODS"
    UpdateMethod="Update" DeleteMethod="Delete">
    <deleteparameters>
        <asp    arameter Name="UserName" />
        <asp    arameter Name="Original_UserName" />
    </deleteparameters>
    ...

The Class (RoleDataObject)

Just like Membership, Roles are set up with their own DataObject. Since there is nothing special about Roles, there are no details regarding their setup in this article. An understanding of how the Membership DataObjects are set up is transferable to how Roles are set up. In Membership, the Microsoft C# object that encapsulates the Membership API is MembershipDataObject.cs. The analogous class for encapsulating the Role API is RoleDataObject.cs.

ObjectDataSource In GridView (Data Control)

Class declarations for Membership Users and Roles have been established in the previous sections of this article. Also, a complete ObjectDataSource object has been placed on an ASP.NET page. The final step is to create the user interface, also known as the user-facing tier of the application or the presentation layer. Because so much of the work is done by the objects created, all that is necessary is to create a simple GridView and associate it with the ObjectDataSource. The steps are as follows:

1. In visual mode of the ASP.NET page designer, drag and drop the GridView data component onto the page associated with the ObjectDataSource created earlier.
2. Enable selecting, deleting, updating, inserting, and sorting.

Figure 8 shows the dialog box associated with configuring the Gridview.

Figure 8. Configuring GridView

A special mention should be made here that DataKeyNames in the GridView control shown below is automatically set. This is because the primary key has been tagged in the MembershipUserSortable class with the attribute [DataObjectField(true)], as shown below. Notice also that since UserName is a property of the MembershipUser class, it was necessary to provide a default property in the class extending MembershipUser. Since this is a Read-only property, only a Get method is declared. (UserName is public virtual on MembershipUser.)

[DataObjectField(true)]
public override string UserName {
  get { return base.UserName;
}

There is one attribute in the GridView that must be set by hand: the primary key must be set in the control. To do this, associate the attribute DataKeyName with UserName. The GridView declaration is shown below.

<asp:GridView ID="GridView1" DataKeyNames="UserName" runat="server"
        AllowPaging="True" AutoGenerateColumns="False"
        DataSourceID="ObjectDataSourceMembershipUser"
        AllowSorting="True">
    <Columns>
    ...
    ...

Conclusion

To wrap things up, you should now be familiar with how to build your own three-tier architected ASP.NET application. In addition, you now have two objects that you can freely use that encapsulate Members and Roles. You could now, for example, use the DetailView control, and in only a few minutes build a complete DetailView interface to Members that performs Navigation, Inserting, Updating, and Deleting of Members. Give it a try!

I have specifically not gone into the implementations of adding, updating, and deleting Members or Roles. If you look at the source code, you will find that I have used the APIs in a very straightforward way. Not much will be gained by describing those calls in much detail here, because I’m sure that if you are still reading this, you, like me, are probably learning this material as you go.

I was fortunate enough to be at MS TechEd in Orlando and PDC in LA this year, and was able to ask many questions of the ASP.NET team. In particular, I would like to thank Brad Millington and Stefan Schackow for putting up with my many questions during those weeks, and Jeff King and Brian Goldfarb for all their help in making this a better article. In some way, this article is payback, so that hopefully they won’t have to answer as many questions in the future.

About the author

Peter Kellner founded 73rd Street Associates in 1990, where he successfully delivered systems for university clinic scheduling, insurance company management, and turnkey physician office management to more than 500 customers nationwide. Ten years later, in 2000, 73rd Street Associates was purchased by a large insurance company, and Peter started a new career as an independent software consultant. Among the technologies he currently is involved with are ASP.NET, Oracle, Java, VOiP, and soon, SQL Server. When not working, Peter spends most his free time biking. He has ridden his bike across the globe. Most recently he and his wife, Tammy, rode across the U.S., from California to Georgia, in just 27 days.

His blog site is http://peterkellner.net. You will find this article and the code posted in the download section.

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnaspp/html/ASPMemManSec.asp

Applies to:

• Microsoft ASP.NET 2.0
• Microsoft Visual Studio 2005
• Microsoft Internet Information Services

Link To Part 2: Implementation

Contents

Abstract
Introduction
Security Considerations
Role-Based Security in a ASP.NET 2.0 Web Site
Conclusion

Abstract

This article is the first of two articles describing the secure use and setup of a three tier solution for managing ASP.NET Membership and Roles. This first article will focus on configuring, using, and, most importantly, securing this solution, as well as providing an overview of how it can be implemented in a typical Microsoft ASP.NET 2.0 Web solution. The Membership and Roles objects will be treated as working without delving into their internal structures. Managing Members and Roles will seem no different than managing data from a simple data source. In the second article, the internals of these controls and objects will be explained in enough detail so developers would be able to build their own using similar techniques.

Introduction

ASP.NET 2.0 extends user authentication directly into the application programming domain. Using a standard .NET Library reference (system.web.security), developers can build full authentication into their application with very little extra work. With this in mind, it is important to remember that a certain level of due diligence is necessary to minimize the possibility that the application being built will not have its security compromised during use.

This article provides an overview of the security mechanisms and shows example security settings that are an essential part of creating a secure environment for Web applications. ASP.NET 2.0 provides many different configuration options that may or may not be deemed necessary, depending on security requirements. Throughout this article, the pros and cons of these configuration options will be discussed.

Security Considerations

Securing the Physical Environment

It is often said that a computer’s security ends at the computer’s front panel power switch. No matter how well the system is secured from an OS level, physical protection is essential. It must be assumed that anyone who has physical access to the computer will always be able to compromise its integrity in one way or another.

For further information on recommended best practices for securing a computer’s physical environment, please review this article on Microsoft TechNet.

Securing the Domain Environment

Best practices for setting up user accounts, passwords, and privileges must be followed. If, for example, a user without privilege is able to directly access the database containing secure data used by the Web application, the application can become compromised.

For further information on securing a computer’s domain environment, the following articles on the Microsoft Security Home Page give a lot of very helpful recommendations and tips.

Securing the .NET Environment

The .NET environment allows the setting of code access security. This means that individual system and application libraries can be associated with different trust levels. This can be very important in, for example, a shared hosting environment where multiple Web applications may be running. Each Web application that is potentially owned by different users may require isolation and protection from each other. In addition, without this isolation, each Web application could potentially impact critical system functions.

In this article, it will be assumed that the ASP.NET user (the user that IIS runs on behalf of) is running with the highest trust level. This would likely be the case when a Web application is running in a dedicated environment. For further information on how code level security could be used to enhance the security of a Web server, see the MSDN article Using Code Access Security with ASP.NET.

ASP.NET’s Relationship with IIS

ASP.NET supports three authentication providers when working with IIS: Forms Authentication, which uses application specific logic; Passport authentication, which is a centralized authentication service provided by Microsoft; and Windows authentication, which uses the authentication provided directly through IIS. The default authentication for ASP.NET projects, Forms Authentication, is used in this article. The authentication mode is specified in the web.config file. The syntax choices are as follows.

<authentication mode = "{Windows|Forms|Passport|None}">
</authentication>

The flow that is followed when a user logs in from a Web client is depicted in the flow chart in this article.

Keep in mind that this article was written in 2001 and is current with the flow of IIS 5.1, not the currently shipping IIS 6.0 or later.

Figure 1. Security Flow between IIS and ASP.NET

Role-Based Security in an ASP.NET 2.0 Web Site

Initial Setup and Configuration

Certain parameters that affect the overall running of an ASP.NET 2.0 Web application are set in the web.config file. Example parameters include a reference to the membership Provider (or database), the strength of the password required, and whether an e-mail is required to register. The relevant section of the web.config file is shown below with sample values for a minimalist security configuration. More details can be found by accessing Visual Studio 2005 help and looking up "Membership Members." Each security parameter is explained there in detail.

<providers>
 <remove name="AspNetSqlMembershipProvider"/>
 <add name="AspNetSqlMembershipProvider"
   type="System.Web.Security.SqlMembershipProvider,
   System.Web, Version=2.0.0.0, Culture=neutral,
   PublicKeyToken=b03f5f7f11d50a3a"
   connectionStringName="LocalSqlServer"
   enablePasswordRetrieval="false"
   enablePasswordReset="true"
   requiresQuestionAndAnswer="true"
   applicationName="/"
   requiresUniqueEmail="false"
   minRequiredPasswordLength="1"
   minRequiredNonalphanumericCharacters="0"
   passwordFormat="Hashed"
   maxInvalidPasswordAttempts="5"
   passwordAttemptWindow="10"
   passwordStrengthRegularExpression=""
   commentTimeout=""/>
</providers>

In addition to the web.config section shown above, the machine.config contains the default connection string to the database associated with Membership. A different connection string can be configured in web.config. To add additional security the connection string can be encoded and the Membership database password can be encrypted. Many articles have been written discussing these tradeoffs. Microsoft’s quick start guides give good examples of how to use encryption in your web.config file.

The Web.Config File / .aspx Page Security

Each Web page in the Web application can be assigned a security level. This is done by specifying what role is required to access the page. The syntax in the web.config file is very straightforward. For example, the following web.config snippet specifies that the MembershipGrid.aspx Web page will only be accessible by a user whose role is assigned as Administrator.

The Web.Config File / Inside .aspx Page Security

It is often necessary to provide more granular security than what is previously described. That is, it may be necessary to protect a control such as a button or an aspx page. To do this, it is necessary to programmatically change the attribute associated with the control to be affected. For example, if it is necessary to hide a delete button based on the user’s role, there are two things that need to be done: first, a method called ShowButtonBasedOnRole should be added to the codebehind class of the Web page. It should return true if the user is permitted in the role requested, and false if the user is not included in the role requested.

protected bool ShowButtonBasedOnRole(string RoleOfInterest)
{
  return User.IsInRole(RoleOfInterest);
}

Then, in the actual aspx page the visibility attribute of the button should be set based on the code-behind method ShowButtonBasedOnRole. The actual declaration of the button looks like the following.

<asp :Button
 ID="Button1" runat="server" Text="Button"
 Visible='<%# (bool) ShowDeleteRowBasedOnRole("administrator") %>'>
</asp>

If a button were to be based on any of multiple roles being set, the passed-in parameter could be changed to a string, and all those roles would be checked before returning with an answer of the whether the user is assigned to one of those roles.

Using the Member/Role Manager aspx Page

To use the aspx page included within this project (Membership.aspx) there are a few things that need to be done. First, the two data classes from the article project files need to be copied and included in the target project’s app_code directory. These two files are MembershipDataObject.cs and RoleDataObject.cs. Then, the aspx file Membership.aspx and its codebehind page, Membership.aspx.cs need to be moved to the current project.

It is very important that this page be protected from being accessed by any user who is not assigned the administrator role. Otherwise, any user would be able to modify any other user’s logon information. To do this, make sure that in the web.config file the Membership.aspx page is protected. Sample lines from a web.config file to accomplish this are as follows.

<system .web>
  <location path="Membership.aspx" >
    <system .web>
      <authorization>
      <allow roles="Administrators"/>
      </authorization>
    </system>
  </location>
</system>

Now that the page is protected, it will be impossible to access this page without having Administrator assigned as a role to the current logged-in user account.

The best way to get around this is to execute the code below one time, then remove that code from the Web server. It could, for example, be in the pageload event of an ASP.NET Web page. Then, after this page has been called, delete the page from the server. At that point, the Membership Management Page will only be accessible by logging into the account admin with the password.

Roles.CreateRole("Administrator");
Roles.CreateRole("User");
Roles.CreateRole("Guest");
Membership.CreateUser("admin", "some strong password here");
Roles.AddUserToRole("admin", "Administrator");

Conclusion

When setting up any Web site, it is important to be cognizant of the users who will use it and understand their associated security requirements. If, for example, the Web site is to be used by an internal group in a company with no external access and no sensitive data, simple security may be sufficient. That is, no encryption, loose password constraints, and so on. Authentication can be used as a convenient method for tracking who is entering data. On the other hand, if the Web site is on the internet and handles confidential data, it is important to lockdown the site as much as possible and only allow authenticated users to access the site.

This article provided a brief introduction on what needs to be considered while setting up security for an ASP.NET Web site. It showed how to add a secure page for modifying Membership and Role information for users logging into the Web site. The next article in this two part series assumes that the security aspects of developing a Web site are understood. It will then describe in detail how the Membership Management page works.