Evjen c14.tex V2 - 01/28/2008 2:39pm Page 717 Chapter 14: Site Navigation Listing 14-34: Locking down the AdminOnly.aspx page in the web.config <configuration> <location path="AdminOnly.aspx"> <system.web> <authorization> <allow roles="Admin" /> <deny users="*" /> </authorization> </system.web> </location> </configuration> Now, because the AdminOnly.aspx page is accessible only to the users who are in the Admin role, the next step is to allow users to login to the application. The application demo accomplishes this task by creating a Default.aspx page that contains a Login server control as well as a TreeView control bound to a SiteMapDataSource control. This simple ASP.NET page is presented in Listing 14-35. Listing 14-35: The Default.aspx page <%@ Page Language="VB" %> <html xmlns="http://www.w3.org/1999/xhtml"> <head runat="server"> <title>Main Page</title> </head> <body> <form id="form1" runat="server"> <div> <asp:Login ID="Login1" runat="server"> </asp:Login> <br /> <asp:TreeView ID="TreeView1" runat="server" DataSourceID="SiteMapDataSource1" ShowLines="True"> </asp:TreeView> <br /> <asp:SiteMapDataSource ID="SiteMapDataSource1" runat="server" /> </div> </form> </body> </html> With the Default.aspx page in place, another change is made to the Web.sitemap file that was originally presented in Listing 14-1. For this example, you add a < siteMapNode > element that works with the new AdminOnly.aspx page. This node is presented here: <siteMapNode title="Administration" description="The Administrators page" url="AdminOnly.aspx" roles="Admin" /> After all items are in place in your application, the next step is to enable security trimming for the site navigation system. 717 Evjen c14.tex V2 - 01/28/2008 2:39pm Page 718 Chapter 14: Site Navigation Enabling Security Trimming By default, security trimming is disabled. Even if you start applying values to the roles attribute for any < siteMapNode > element in your web.config file, it does not work. To enable security trimming, you must fine-tune the provider declaration for the site navigation system. To make the necessary changes to the XmlSiteMapProvider, you need to make these changes high up in the configuration chain, such as to the machine.config file or the default web.config file, or you can make the change lower down, such as in your application’s web.config file. This example makes the change in the web.config file. Figure 14-36 To alter the XmlSiteMapProvider in the web.config file, you first clear out the already declared instance. After it is cleared, you then redeclare a new instance of the XmlSiteMapProvider, but this t ime you enable security trimming, as illustrated in Listing 14-36. 718 Evjen c14.tex V2 - 01/28/2008 2:39pm Page 719 Chapter 14: Site Navigation Listing 14-36: Enabling security trimming in the provider <configuration> <system.web> <siteMap> <providers> <clear /> <add siteMapFile="web.sitemap" name="AspNetXmlSiteMapProvider" type="System.Web.XmlSiteMapProvider, System.Web, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" securityTrimmingEnabled="true" /> </providers> </siteMap> </system.web> </configuration> Figure 14-37 719 Evjen c14.tex V2 - 01/28/2008 2:39pm Page 720 Chapter 14: Site Navigation From this example, you can see that a new XmlSiteMapProvider is defined and the securityTimmingEn- abled attribute is then set to true (shown in bold). With security trimming enabled, the roles attribute in the < siteMapNode > element is utilized in the site navigation system. To test it out for yourself, run the Default.aspx page. You are first presented with a page that does not include the link to the administration portion of the page, as illustrated in Figure 14-36. From this figure, you can see that the Administration link is not present in the TreeView control. Now, however, log in to the application as a user contained in the Admin role. You then see that, indeed, the site navigation has changed to reflect the role of the user, as presented in Figure 14-37. Security trimming is an ideal way of automatically altering the site navigation that is presented to users based upon the roles they have in the role management system. Nesting SiteMap Files You are not required to place all your site navigation within a single Web.sitemap file. In fact, you can spread it out into multiple .sitemap files if you wish and then bring them all together into a single .sitemap file — also known as nesting .sitemap files. For instance, suppose you are using the sitemap file from Listing 14-1 and you have a pretty large amount of site navigation to add under the area of Entertainment. You could put all this new information in the current Web.sitemap file, or you could keep all the Entertainment links in another sitemap file and just reference that in the main sitemap file. In the simplest case, nesting sitemap files is easily achievable. To see it in action, create a new .sitemap file (called Entertainment.sitemap ) and place this file in your application. An example Entertain- ment.sitemap file is presented in Listing 14-37. Listing 14-37: The Entertainment.sitemap <?xml version="1.0" encoding="utf-8" ?> <siteMap xmlns="http://schemas.microsoft.com/AspNet/SiteMap-File-1.0" > <siteMapNode url="Entertainment.aspx" title="Entertainment" description="The Entertainment Page"> <siteMapNode url="Movies.aspx" title="Movies" description="The Latest in Movies" /> <siteMapNode url="Fashion.aspx" title="Fashion" description="The Latest in Fashion" /> </siteMapNode> </siteMap> You can place the Entertainment.sitemap in the root directory where you also have the main Web.sitemap file. Now, working from the sitemap file that from the earlier Listing 14-1, you make the following addition to the bottom of the list as presented in Listing 14-38. Listing 14-38: Additions to the Web.sitemap file <siteMapNode siteMapFile="Entertainment.sitemap" /> 720 Evjen c14.tex V2 - 01/28/2008 2:39pm Page 721 Chapter 14: Site Navigation Instead of using the standard url , title ,and description attributes, you just point to the other sitemap file to be included in this main sitemap file using the siteMapFile attribute. Running this page gives you results similar to those presented in Figure 14-38. Figure 14-38 Another approach to nesting sitemap files is to build a second provider in the sitemap provider model definitions and to then use the provider attribute within the < siteMapNode > element to reference this declaration. To accomplish this task, you first add a new sitemap provider reference in the web.config file. This is illustrated in Listing 14-39. Listing 14-39: Using another provider in the same Web.sitemap file <configuration> <system.web> <siteMap> <providers> <add siteMapFile="Entertainment.sitemap" name="AspNetXmlSiteMapProvider2" type="System.Web.XmlSiteMapProvider, System.Web, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" /> </providers> </siteMap> </system.web> </configuration> From this bit of code, you can see that a second provider is defined. Defining a second sitemap provider does not mean that you have to use the < clear / > element in the < provider > section, but instead, you simply define a new provider that has a new name. In this case, the name of the provider is AspNetXml- SiteMapProvider2 . Also, within this provider definition, the siteMapFile attribute is used to point to the name of the sitemap file that should be utilized. With this in place, you can then reference this declaration by using the provider attribute within the < siteMapNode > element of the Web.sitemap file. To add the Entertainment.sitemap file in this manner, your < siteMapNode > element should take the form presented in Listing 14-40. 721 Evjen c14.tex V2 - 01/28/2008 2:39pm Page 722 Chapter 14: Site Navigation Listing 14-40: Using a second provider in the Web.sitemap file <siteMapNode provider="AspNetXmlSiteMapProvider2" /> This gives you the same results as those shown in Figure 14-38. Besides providing another way of nesting sitemap files, you gain a lot of power using the provider attribute. If you build a new sitemap provider that pulls sitemap navigation information from another source (rather than from an XML file), you can mix those results in the main Web.sitemap file. The end result could have items that come from two or more completely different data sources. Summary This chapter introduced the navigation mechanics that ASP.NET 3.5 provides. At the core of the naviga- tion capabilities is the power to detail the navigation structure in an XML file, which can then be utilized by various navigation controls — such as the new TreeView and SiteMapPath controls. The powerful functionality that the navigation capabilities provide saves you a tremendous amount of coding time. In addition to showing you the core infrastructure for navigation in ASP.NET 3.5, this chapter also described both the TreeView and SiteMapPath controls and how to use them throughout your a ppli- cations. The great thing about these controls is that, right out of the box, they can richly display your navigation hierarchy and enable the end user to work through the site easily. In addition, t hese con- trols are easily changeable so that you can go beyond the standard appearance and functionality that they provide. Along with the TreeView server control, this chapter also looked at the Menu server control. You will find a lot of similarities between these two controls as they both provide a means to look at hierarchical data. Finally, this chapter looked at how to achieve URL mapping, as well as how to localize your Web .sitemap files and filter the results of the site navigation contents based upon a user’s role in the role management system. 722 Evjen c15.tex V2 - 01/28/2008 2:44pm Page 723 Personalization Many Web applications must be customized with information that is specific to the end user who is presently viewing the page. In the past, the developer usually provided storage of personal- ization properties for end users viewing the page by means of cookies, the Session object, or the Application object. Cookies enabled storage of persistent items so that when the end user returned to a Web page, any settings related to him were retrieved in order to be utilized again by the application. Cookies are not the best way to a pproach persistent user data storage, however, mainly because they are not accepted by all computers and also because a crafty end user can easily alter them. As you will see in Chapter 16, ASP.NET membership and role management capabilities are ways that ASP.NET can conveniently store information about the user. How can you, as the developer, use the same mechanics to store custom information? ASP.NET 3.5 provides you with an outstanding feature — personalization. The ASP.NET personal- ization engine provided with this latest release can make an automatic association between the end user viewing the page and any data points stored for that user. The personalization properties that are maintained on a per-user basis are stored on the server and not on the client. These items are conveniently placed in a data store of your choice (such as Microsoft’s SQL Server) and, therefore, the end user can then access these personalization properties on later site visits. This feature is an ideal way to start creating highly customizable and user-specific sites without building any of the plumbing beforehand. In this case, the plumbing has been built for you! The personalization feature is yet another way that the ASP.NET team is making developers more pro- ductive and their jobs easier. The Personalization Model The p ersonalization model provided with ASP.NET 3.5 is simple and, as with most items that come with ASP.NET, it is an extensible model as well. Figure 15-1 shows a simple diagram that outlines the personalization model. Evjen c15.tex V2 - 01/28/2008 2:44pm Page 724 Chapter 15: Personalization Server Controls Web Parts Interfaces Control PersonalizationProfile API Data Stores Custom Data Store SQL Server 7.0/2000/2005/2008 Figure 15-1 From this diagram, you can see the three layers in this model. First, look at the middle layer of the per- sonalization model — the Personalization Services layer. This layer contains the Profile API. This new Profile API layer enables you to program your end user’s data points into one of the lower-layer data stores. Also included in this layer are the server control personalization capabilities, which are important for the Portal Framework and the use of Web Parts. The Portal Framework and Web Parts are discussed in Chapter 17. Although certain controls built into ASP.NET can utilize the personalization capabilities for storing information about the page settings, you can also use this new engine to store your own data points. As with Web Parts, these points can be used within your ASP.NET pages. Below the Personalization Services layer, you find the default personalization data provider for working with Microsoft’s SQL Server 2008, 2005, or 2000, as well as the new Microsoft SQL Server Express Edition files. You are not limited to just this one data store when applying the personalization features of ASP.NET 3.5; you can also extend the model and create a custom data provider for the personalization engine. You can read about how t o create your own providers in Chapter 13. Now that you have looked briefly at the personalization model, you can begin using it by creating some stored personalization properties that can be used later within your applications. 724 Evjen c15.tex V2 - 01/28/2008 2:44pm Page 725 Chapter 15: Personalization Creating Personalization Proper ties The nice thing about creating custom personalization properties is that you can do it so easily. After these properties are created, you gain the capability to have strongly typed access to them. It is also possible to create personalization properties that are used only by authenticated users, and also some that anonymous users can utilize. These data points are powerful — mainly because you can start using them immediately in your application without building any underlying infrastructures to support them. The first step is to create some simple personalization properties. Later, you learn how to use these personalization properties within your application. Adding a Simple Personalization Property The first step is to decide what data items from the user you are going to store. For this example, create a few items about the user that you can use within your application; assume that you want to store the following information about the user: ❑ First name ❑ Last name ❑ Last visited ❑ Age ❑ Membership Status ASP.NET has a heavy dependency on storing configurations inside XML files, and the ASP.NET 3.5 personalization engine is no different. All these customization points concerning the end user are defined and stored within the web.config file of the application. This is illustrated in Listing 15-1. Listing 15-1: Creating personalization properties in the web.config file <configuration> <system.web> <profile> <properties> <add name="FirstName" /> <add name="LastName" /> <add name="LastVisited" /> <add name="Age" /> <add name="Member" /> </properties> </profile> <authentication mode="Windows" /> </system.web> </configuration> 725 Evjen c15.tex V2 - 01/28/2008 2:44pm Page 726 Chapter 15: Personalization Within the web.config file and nested within the < system.web > section of the file, you create a < profile > section in order to work with the ASP.NET 3.5 personalization engine. Within this < profile > section of the web.config file, you create a < properties > section. In this section, you can define all the properties you want the personalization engine to store. From this code example, you can see that it is rather easy to define simple properties using the < add > element. This element simply takes the name attribute, which takes the name of the property you want to persist. You start out with the assumption that accessing the page you will build with these properties is already authenticated using Windows authentication (you can read more on authentication and authorization in the next chapter). Later in this chapter, you look at how to apply personalization properties to anonymous users as w ell. The capability to apply personalization properties to anonymous users is disabled by default (for good reasons). After you have defined these personalization properties, it is just as easy to use them as it is to define them. The next section looks at how to use these definitions in an application. Using Personalization Properties Now that you have defined the personalization properties in the web.config file, it is possible to use these items in code. For example, you can create a simple form that asks for some of this information from the end user. On the Button_Click event, the data is stored in the personalization engine. Listing 15-2 shows an example of this. Listing 15-2: Using the defined personalization properties VB <%@ Page Language="VB" %> <script runat="server"> Protected Sub Button1_Click(ByVal sender As Object, ByVal e As System.EventArgs) If Page.User.Identity.IsAuthenticated Then Profile.FirstName = TextBox1.Text Profile.LastName = TextBox2.Text Profile.Age = TextBox3.Text Profile.Member = Radiobuttonlist1.SelectedItem.Text Profile.LastVisited = DateTime.Now().ToString() Label1.Text = "Stored information includes:<p>" & _ "First name: " & Profile.FirstName & _ "<br>Last name: " & Profile.LastName & _ "<br>Age: " & Profile.Age & _ "<br>Member: " & Profile.Member & _ "<br>Last visited: " & Profile.LastVisited Else Label1.Text = "You must be authenticated!" End If End Sub </script> 726 . on storing configurations inside XML files, and the ASP. NET 3. 5 personalization engine is no different. All these customization points concerning the end user are defined and stored within the web.config file. control. This simple ASP. NET page is presented in Listing 14 - 35 . Listing 14 - 35 : The Default.aspx page <%@ Page Language="VB" %> <html xmlns="http://www.w3.org/1999/xhtml"> <head. in action, create a new .sitemap file (called Entertainment.sitemap ) and place this file in your application. An example Entertain- ment.sitemap file is presented in Listing 14 -37 . Listing 14 -37 :