Asp. NET security issues--froms validation of the specific introduction (medium)

Preface: Today is the Dragon Boat Festival, everybody happy holiday! Don't forget our traditional festivals,!!!. Because the previous article has talked about some of the theories related to forms validation, this article mainly describes how to use forms validation in general and gives some code. There may be some topic before the garden has friends to talk about, if there is duplication, then the right to review also line!

The topic of this article is as follows:

Enable Forms authentication

Storage of user Information

Some uses of Web.config configuration

Forms validation simple Introduction to Features

Cookie issues in forms validation

Enable Forms authentication

I'm sure you know very well how to enable forms validation, but here I'm just a little wordy.

All we need to do is configure the following in the Web.config file:

<authentication mode= "Forms"/>

After that, the ASP. NET runtime is aware that we have enabled forms validation and that the FormsAuthenticationModule module is activated during the verification phase of the lifecycle.

It's also important to note that the:<authentication/> element node can only be configured in Web.config in the application's root folder. If you use this node in a subfolder, you will get an error. This also shows that each application can define only one authentication type.

And in the <authentication/> node, we can also make more settings. As follows:

<authentication mode="Forms ">
　　　　　　 <forms name="MyCookie"
　　　　　　　　　　　　　　 loginUrl="Login.aspx"
　　　　　　　　　　　　　 timeout="60"
　　　　　　　　　　　　　 path="/"
　　　　　　　　　　　　　 protection="All">

　　　　　　 </forms>
　 </authentication>

Let's look at the meaning and purpose of the attributes in the <forms> node:

Name: Defines the names of the authentication cookies. Because we put the authenticated ticket in a cookie, we have to give the authentication cookie a unique name to prevent conflicts with cookies in other applications.

Loginurl: You can tell from the English name that it's about logging in. It actually indicates which page to redirect the user to to login.

Timeout: Sets the duration, in minutes, of the authentication cookie. And this time is a relative time, which means that each time the user is authenticated, the cookie's duration is reset. If the user does not initiate a request to the server within 60 minutes, the cookie expires, and then if the user initiates the request again, the user name and password will be re-enter.

Path: Set the path of the cookie's save, generally set to "/", we do not easily change.

As we have said before, our authenticated ticket is encrypted and then stored as a cookie, and then the cookie is sent to the client. When the client requests again, the server side will resolve the cookie information sent by the client, we must confirm: The client sent the cookie information we sent from the server before the past, that is, we have to determine whether our cookies in the client has been tampered with.

So, this is the purpose of the attribute protection in <forms/>. There are four values for protection:

Encryption: Encrypts the content information of the cookie.

Validation: Adds a MAC (message authentication code) to the contents of the cookie so the server can determine if the cookie has been tampered with.

None: Disabling encryption and tampering checks

All: Enable both encryption and tamper checking.

By default, "All" because it can encrypt data into a cookie and authenticate cookies that are returned to the server side.