Beginning ASP.NET 2

Membership and Identity

6.If you run the application again now, you should be able to log in as any of the user accounts and access the site as before. If you change the permissions for one of the roles, all members of that role will be affected, hence you could block access to all non-administrative users if you wanted.

How It Works

All of the changes made in this example were performed via the magic Web Site Administration interface, which simplifies the process of adding role definitions and access rules. If you were to do this by hand, as you will see in just a moment, you would have to manipulate the contents of the Roles table in the AspNetDB.mdf database that was shown earlier to include two role definitions, and then add users to those roles by changing the UsersInRoles table by hand. Then you would have to manipulate the Web.config file to change the access permissions to the site.

This configuration process was all handled for you automatically by the tool, so it’s made configuration and administration quite a lot simpler! However, this is a Visual Web Developer and Visual Studio 2005 feature, not an ASP.NET feature, so you would have to do this by hand if you didn’t have access to the VWD environment.

If you flick back to the Source View of your Web.config file, you’ll see the following changes have been made (shown with a gray background):

<roleManager enabled=”true” /> <authorization>

<allow users=”?” />

<allow roles=”administrators” />

<allow roles=”users” /> </authorization>

In addition, the process of enabling roles has modified the user profile database slightly too, by adding two new tables: one to store roles and one that tells you which users are members of which roles (see Figure 4-28).

Figure 4-28

129

Chapter 4

Authentication

One area not yet discussed is that of how the authentication works for this application, and what options are available in ASP.NET for authentication. The examples so far have all relied on what’s known as Forms authentication. So, what is Forms authentication, and what are the other options available?

Forms authentication: Login requests are made by filling in a form on a web page and submitting that form to the server. Once the server receives the request, a cookie is written to the user’s local machine, and this cookie is passed back to the server by the browser along with each request that is sent so that the user remains authenticated for as long as is required.

Windows authentication: Login pages pass user credentials to a web server (IIS only, not the web server built into VWD). The web server then handles the authentication using whichever method is configured on the virtual directory that the application is running within. IIS hooks in to the Windows operating system and Active Directory domain structures, which means that it can rely on user profiles that are stored externally, and use standard Windows credentials to log in to the site. Depending on the configuration of your site, and depending on which user account you have used to log in to your machine, you may not even have to log in to the site directly, because your current Windows credentials can be passed to the web server automatically for authentication. This is really handy when it comes to developing intranet applications.

Passport authentication: Login credentials are passed to a Microsoft Passport server where user profiles are stored centrally. You may be familiar with this from logging in to a Hotmail account. And because you can configure Windows to log on to a Passport account on start up, you can access your Hotmail inbox without even having to type a password.

Forms Authentication Model

This section looks at how Forms authentication works. Consider the following scenario:

The user — let’s call him Bob — wants to view Page A, which can’t be accessed by anonymous users, so when Bob tries to view Page A, the browser instead displays a login page, as shown in Figure 4-29.

Browser sends request for PageA to the server

Browser

Server

Server refuses anonymous access and sends login page instead

Figure 4-29

130

Membership and Identity

Bob is now looking at a login page. Because Bob has registered with this site previously, he logs in to the site using his username and password combination. Figure 4-30 shows the interaction between Bob’s browser and the server.

Browser sends a login request to the server

Browser

Server

Server authenticates Bob and returns Page A along with a cookie to the browser

Figure 4-30

Bob can now view Page A and is a happy user. Now Bob wants to view Page B by following a link from Page A. Along with the request for the page, Bob’s browser sends a copy of the cookie to the server to let the server know that it’s Bob who’s trying to view the page. The server knows who Bob is, and likes Bob, so sends Bob Page B as requested, as shown in Figure 4-31.

Browser requests Page B and passes a copy of the cookie

Browser

Server

Server accepts cookie and sends back Page B

Figure 4-31

If Bob now requests the site’s home page, the browser will still tack on the cookie to the request, so even though the home page is not restricted content, the cookie is still sent to the server. Because the page isn’t restricted, the server doesn’t worry about the cookie, ignores it, and sends back the home page.

Bob then heads back to Page A. Because the cookie is still fresh on Bob’s machine, the cookie is still sent to the server. The server is still happy with Bob, so it lets Bob view the page.

Bob goes off and makes himself a coffee. He then makes some lunch. By the time he gets back to his computer, 25 minutes have elapsed. Bob now wants to view Page B again, but the cookie on his machine has expired. The server doesn’t receive a cookie along with the page request, so Bob has to log back in again.

131

Chapter 4

Cookies on a user’s machine will normally be set to expire after a specific amount of time has elapsed. In this scenario, the server gives out cookies with a 20-minute expiry, which means that as long as the user keeps making requests within 20 minutes of each other, the cookie will remain active. However, more than 20 minutes away from the site and the user will have to log back in to the site to view restricted content.

You will note that the login page built in the earlier examples included a box that offered you the “remember my details for next time” option. This will write a more permanent cookie to your browser’s cookie collection so that your account name will be prepopulated when you revisit the site. Because you should never store password information in a cookie, you should always have to enter your password, but at least your username field will be filled in for you on each visit.

Other methods of authentication (Windows and Passport) provide the end user with a similar experience. For example, the Windows authentication model relies on the web server (which will likely be IIS) to control access to the site, but can also incorporate the timeout mechanism to block users that have been idle for too long. To configure Windows authentication, you would need to specify which users or roles from the corporate Active Directory (AD) domain could access a site. These users could then access the site whenever they are logged on using their login details to a PC on the corporate network.

It’s also possible to view a Windows authenticated site from outside of the corporate environment, though you will be asked to enter your standard Windows logon credentials when you attempt to access a page protected by Windows authentication.

Passport authentication isn’t as widely adopted as Microsoft perhaps would have liked, but some sites on the Internet do link up to the Passport network to handle web site authentication (for example, Expedia.com). Passport authentication relies on the entire repository of user accounts being accessible from anywhere in the wired world, a bit like a central Active Directory for web accounts.

This book uses Forms authentication to handle all authentication with the Wrox United application.

Wrox United Security

The Wrox United site that you’ve been working on so far will need to have some security applied to it if you want to be able to include some personalization in the site. In the finished site (www.wroxunited.net) you’ll see that there is shopping cart functionality built in to the site. Additionally, the finished site will also have an administration area, where you can edit fixtures, team members, and much more. This all means that you’re going to have to add some users and roles at some stage — because you will have gained plenty of experience of using the configuration tool, you will now be able to perform the first stage in this process. The next Try It Out walks you through the user accounts and roles configuration for the Wrox United site. At this stage, you don’t have to worry about locking down parts of the site; that’s a task for later in the book.

Try It Out

Configuring Security in the Wrox United Site

1.Start by opening your chapter version of the Wrox United site in VWD. Once it’s opened, click the Website menu and select ASP.NET Configuration. This will launch the configuration tool for the site. Figure 4-32 shows the configuration screen that is displayed for the finished version of the site.

132

Membership and Identity

Figure 4-32

2.Click the Security link to go into the section where you can configure users and roles. As you did previously in this chapter, launch the security setup wizard. As you walk through the wizard, select the following:

The application will be used over the Internet.

Roles are enabled.

If they don’t yet exist, create roles for Administrator, FanClubMember, Manager, Owner, and Reporter (see Figure 4-33).

Finally, create some user accounts — start with at least five so you can have at least one user in each role. The user accounts predefined with the Wrox United application are shown in Figure 4-34.

133

Chapter 4

Figure 4-33

Take a look at the configuration for the finished application and you’ll see that the preconfigured user accounts are each members of different roles, so while the ChrisH account is a member of the Reporter role, Jim is a member of the Owners role, and Lou is a member of the Fan Club.

3.Once you finish the wizard you need to make a couple of subfolders within the WroxUnited directory that will contain specific areas of the site — the Admin and the FanClub sections.

4.Now you can head into the section for managing Access Rules and add the following rules:

For the main WroxUnited folder, allow anonymous access.

For the FanClub folder, firstly deny access to all users, then add a second rule to only allow access to members of the FanClub role.

For the Admin folder, deny access to all users.

Because these user accounts and roles are not going to be used at this stage, you don’t need to do any further work to the site just yet. However, this preparation work will pave the way for further work later down the line when you create other pages in the site.

134

Membership and Identity

Figure 4-34

How It Works

With the Wrox United application, you have access to the configuration of a fully functional web application. Feel free to have a look through this configuration using both the administration tool and the Web.config file to see how the basic permissions are enabled. This example is only a taste of what will come later in the book, because Chapter 11 covers the details of role-based access to a site and shows you different techniques for enabling and disabling content by role.

The code generated for filtering access to the FanClub folder has been added to the Web.config file that lives within the FanClub folder. This code appears as follows:

<?xml version=”1.0” encoding=”utf-8”?> <configuration>

<system.web>

<authorization>

<allow roles=”FanClubMember” /> <deny users=”*” />

</authorization>

</system.web>

</configuration>

135

Chapter 4

Notice that the FanClubMember role has been defined as the only role that has permission to access the content in this folder.

The directory-level permission created in this example has created a restricted zone in the site. Chapter 11 walks through some examples using the Administration section and the Fan Club sections, demonstrating different parts of ASP.NET 2.0 technology. These examples will rely on an understanding of the foundations built in this section.

Summar y

This chapter discussed the basics of security, the concept of identity, and the process involved in logging on to a site. These are familiar concepts to anyone who spends time on the Internet, surfing fan sites, community portals, or online shops, and because these concepts are so universal, you’ve seen how ASP.NET 2.0 has been designed to make the process of creating sites that use this functionality.

The core concepts to understand are as follows:

Identity: The concept of an individual as described by a set of attributes that make that individual unique.

Authentication: The concept of identifying a user to a server by passing a set of credentials to the server. If the server can identify the user attempting to connect, he or she will be authenticated.

Authorization: The process of taking authenticated user credentials and comparing them against a set of access control list information, providing the answer to the question “can this user access the requested resource?”

Personalization: The capability to provide information that is specific to the currently logged-in user.

Membership: The concept of belonging. This chapter considered the concept of users being members of specific roles.

The next chapter expands on the concept of personalization and looks at how ASP.NET sites can be personalized.

Exercises

1.Change the configuration of your Chapter 4 web site to allow anonymous access, but to deny access to one specific user account.

2.Add a subfolder to the Chapter 4 web site called Admin. Within this folder, add a page called MainAdmin.aspx with a LoginName control on it and any other controls you might want. Change the access permissions for that specific folder so that only members of the Administrators group can view the page.

136

5

Styling with Themes

The process of developing any web application usually revolves around two main areas: functionality and appearance. The functionality aspect of a web application includes the structure of the site, the behavior of the controls, the user experience, code for securing the application, what happens when the user clicks a button, and so on. The appearance of a site is somewhat more aesthetic, and involves the use of color, images, the layout of pages, and to some extent, the style of code that is rendered to the browser. A successful application will strike a good balance between the two sides, providing a visually pleasant site that is easy to use and to work with for all users, and it’s the balancing act between the two sides where many sites fail.

This chapter starts by introducing the fundamental tools available for styling web applications, before introducing the styling capabilities of Visual Web Developer. It goes through the basics of styling individual controls before moving style information into a separate CSS file, then introduces themes — a new technique for styling pages and sites.

In this chapter, the following topics are discussed:

Styling a web site, from styling individual elements to the use of CSS style sheets

Developing style sheets for an application in VWD

Using ASP.NET 2.0’s themes and skins to rapidly develop styled web content that conforms to a standard look and feel

Adding style to the Wrox United site using themes and skins

Additionally, this chapter also discusses the concepts of usability and accessibility, which are two important areas of web design that should be considered when developing any web site.

Styling a Site

It may sound obvious, but the front page appearance of a site is the first thing your visitors will see, and although we are told never to judge a book by its cover (particularly in the case of Wrox author mug shots!), most of us will still have an initial impression of a site based on its appearance, whether it’s a fairly neutral response (it’s ok, it does the job, where’s the search box?), a positive response

Chapter 5

(neat, slick, pretty, show me more!), or a negative response (yuk, messy, I’m going somewhere else!). Initial impressions count, so it’s important that you get them right.

In any site design there are common elements; for example, some kind of header that gives you a company name, an idea of what the site is about, or a reflection of why you are looking at the site. You will also find areas such as menus, search boxes, groups of links, footers, and so on. A page without these sorts of elements will only be relevant to a specific audience; for example, a developer proving a concept, or the reader of a book who’s trying out some new technology. Positioning these elements precisely is important, as is structuring the content to fit the style of site you’re trying to develop.

Styling and laying out a site is an integral part of web development. Although laying out a site is one aspect, the styling of a site can be a bit trickier. This chapter focuses on styling pages and the rules and hierarchy involved in this process — laying out elements and positioning items on a page is part of web design that is discussed throughout this book.

Style Attributes

The easiest and quickest way to change the way an element appears on a page is to add a style attribute. The style attribute can be applied to any visible element on a page. For example:

<div style=”font-weight:bold;color:red;border-bottom:solid 2pt navy”>This is a

styled “div” tag</div>

Figure 5-1 shows how this style attribute will look in Internet Explorer.

Figure 5-1

In the following Try It Out, you start by creating a web site that you can use to host all of the examples in this chapter.

Try It Out

Styling a Simple Page, Part 1 — Element by Element

1.In VWD, open the starter web site called Chapter05 (C:\BegASPNET2\Chapters\Begin\). This starter site contains just a few files to give you a head start on the examples within this chapter.

2.Add a new blank .aspx page and call it Default.aspx. Switch straight to Source View and type in the following highlighted lines of code between the Form tags:

138