The only other page in this scenario that required me to add
code was the MyProfile.aspx page. This page looks like this:
Figure 4
The page itself was pretty simple to implement. I simply
added a few asp:label controls on the page, as well a listbox for the roles.
Populating these controls with the profile and role information involved added
a Page_Load event with 7 lines of code like so:
Listing 5
protected void Page_Load(object sender, EventArgs e) {
Country.Text = Profile.Country;
Gender.Text = Profile.Gender;
Age.Text = Profile.Age.ToString();
RoleList.DataSource = Roles.GetRolesForUser(User.Identity.Name);
RoleList.DataBind();
}Note that the profile object is strongly typed – which means
profile properties will get statement completion and compilation checking in VS
2005 with it. I can also then query the role management system to retrieve an
array of all the roles the current user belongs to and then databind this to
the listbox control.
Since the MyProfile.aspx page requires a user to be logged
in (otherwise retrieving profile information about them doesn’t make a lot of
sense), I also added a <location> based authorization control tag in my
web.config file:
Listing 6
<location path="MyProfile.aspx">
<system.web>
<authorization>
<deny users="?"/>
<allow users="*"/>
</authorization>
</system.web>
</location>
This is the same configuration I would have added in ASP.NET
V1.1 – and basically tells the system to deny all users who aren’t logged in
(the ? = anonymous), and then allow all users who are logged in (the * = all).
Those who aren’t logged in will get automatically
re-directed to the login.aspx page. The <asp:login> control can be used
there to allow users who have already registered to log-in without the
developer having to write any custom code.
