Asp. NET security issues--forms verification of the specific introduction (last article)

In ASP.net, the most important reason for forms validation is flexibility. Because the forms verification thin talk up also really quite a lot, and I do not want to hastily say finish, that to everybody and oneself are irresponsible.

The topic of this article is as follows:

How Forms Validation Works

The APIs in forms validation

How Forms Validation Works

We know that forms validation is primarily based on cookies, and that the white point is to save the user information in a cookie and then send it to the client, and then parse the cookie message sent by the client, parse it, and verify it. About the working principle and method of cookieless, I do not repeat here, you can refer to my another article: talking about the internal mechanism of asp.net (one).

When an anonymous user requests a resource and a page that needs to be authenticated, the URL authorization module redirects the user to the login page if forms validation is used. The URL that was previously requested will be saved until the user logs in correctly, and then turns to the requested page again. I think everyone should have used it.

Let's take a look at what happened when we logged in, and look at the specific process of login. Please also pay attention to some of the terms I use, because these terms in the forms have a specific object, you can see later, very important.

1. There is a login form in the browser, to enter the user name and password and other vouchers, by submitting to the server's ASP.net website to audit, check the certificate is correct.

2. If the credentials are correct, an "authentication ticket" will be created on the server side. The authentication ticket contains the encrypted user information.

3. This ticket is then written to the cookie server side and sent to the client.

4. The user is then redirected to the URL they originally requested.

Note: You may have questions: Where exactly is the URL of the original request saved? Don't worry, now just understand the process above OK.

5. The 4th step above is to turn to the original requested URL, assuming that the original request page is Default.aspx, then it is now from the login page login.aspx to the Default.aspx page, This is because the authenticated ticket cookie already exists in the client's browser. At this point, the shift to the Default.aspx page actually initiates a request to the server side, so as we've said before: Each request is passed from one level of ASP.net pipeline to the next, going through the asp.net lifecycle: application_ Beginrequest,application_authenticaterequest ... (I hope you understand)

But this request is the same as the first request we initiated, why?

The first time we asked for the Default.aspx page, we did not provide any tickets to indicate our identity, but this time we have logged in, and our browser already has a cookie for our authenticated ticket, at Application_ In the AuthenticateRequest event, the Forms validation module obtains the identity cookie, and then populates the Context.User with the information in the cookie.

After the validation module is processed, the authorization module works. In fact, the URL authorization module will use the information we have previously populated in Context.User to verify that the user is authorized to access the requested resource or page.

The APIs in forms validation

Before implementing forms authentication, let's look at the APIs that make up forms validation and the related classes:

FormsAuthenticationModule: HTTP module to authenticate each request

FormsAuthentication: The methods and properties that are commonly used in forms validation (very important)

Formsidentity:forms authentication identification.

FormsAuthenticationTicket: The authentication of the bill, the user's information to encrypt the product, we generally write it as a cookie, before we talked about.

The above class is under System.Web.Security.