出自：Chris Hart，Jokn Kauffman，David Sussman．《Beginning 2.0 with C# 》[M]．Wrox，2006：125-131．英文原文AuthenticationOne area not yet discussed is that of how the authentication works for this application, and what options are available in for authentication. The examples so far have 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. When 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 login to the site. Depending on the configuration of your site, and depending on which user account you 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 startup, 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 loginpage, as shown in Figure 4-29.Figure 4-29❑Bob is now looking at a login page. Because Bob registered with this site previously, he logs into the site using his username and password combination. Figure 4-30 shows the interaction between Bob’s browse r and the server.Figure 4-30❑Bob can now view Page A and is a happy user. Next, 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 it sends Bob Page B as requested.Figure 4-31❑If Bob now requests the site’s home page, the browser will 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 abou t the cookie, ignores it, and sends back the home page.❑Bob then heads back to Page A. Because the cookie is fresh on Bob’s machine, the cookie is 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.Cookies on a user’s machine are normally 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.The login page built in the earlier examples included a box that offered you the “remember my details for next time” option. This writes a more permanent cookie to your browser’s cookie collection so that your account name is pre-populated 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 is 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 it can also incorporate the timeout mechanism to block users that have been idle for too long. To configure Windows authentication, you need to specify which users or roles from the corporate Active Directory (AD) domain can access a site. These users can 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 Win dows authenticated site from outside of the corporate environment, though you are asked to enter your standard Windows logon credentials when you attempt to access a page protected by Windows authentication.Server accepts cookie and sends back Page B Browser requests Page B and passes a copy of the cookie Browser Server Membership and Identity Passport authentication isn’t as widely adopted as Microsoft perhaps would have liked, but some sites on the Internet do link to the Passport network to handle web site authentication (for example,).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 SecurityThe Wrox United site that you’ve been working on so far needs to have some security applied to it if you want to be able to include some personalization in the site. In the finished site (),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 have gained plenty of experience of using the configuration tool, you can now 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 Site1. Open the final version of the Wrox United site in VWD. Then click the Website menu and select Configuration. This launches the configuration tool for the site. Figure 4-32 shows the configuration screen that is displayed for the finished version of the site.Figure 4-322. Click the Security link to go to 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.❑Roles should be defined for Administrator, FanClubMember, Manager, Owner, and Reporter (see Figure 4-33).3. Look at the user accounts. The user accounts predefined with the Wrox United application are shown in Figure 4-34.4. Take a look at the configuration for the finished application. 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.5. After you finish the wizard, look at a couple of subfolders within the WroxUnited directory that contain specific areas of the site—the Admin and the FanClub sections. These areas have some access restrictions on them.Figure 4-33Figure 4-346. Go to the section for managing Access Rules and you’ll see the following rules:❑For the main WroxUnited folder, anonymous access is allowed.❑For the FanClub folder, only members of the FanClub role can access the folder—all other users are denied access.❑For the Admin folder, access is denied to all users.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 is as follows: <?xml version=”1.0”encoding=”utf-8”?><configuration><system.web><authorization><allow roles=”FanClubMember”/><deny users=”*”/></authorization></system.web></configuration>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 2.0 technology. These examples will rely on an understanding of the foundations built in this section.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. Because these concepts are so universal, you’ve seen how 2.0 is 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 sites can be personalized.中文翻译身份验证一个尚未讨论的问题是应用程序的身份验证是如何实现的，以及为身份验证提供了哪些选择。