关于ASP.NET的毕业设计论文外文翻译

出自：Chris Hart，Jokn Kauffman，David Sussman．《Beginning 2.0 with C# 》

[M]．Wrox，2006：125-131．

英文原文

Authentication

One 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 login

page, 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.