Asp.net verifies the form program

3. Create the Default. aspx and Login. aspx pages on the website.
In Login. put the Login and CreateUserWizard controls in the aspx page (because one user in the new library does not exist, the CreateUserWizard control is only used to create a test user. After the user is created, delete the control)
Add some content to the Default. aspx page.
When we access Default. aspx, it is automatically transferred to Login. aspx for verification.

Ii. Custom implementation
When using the first method, a database is required. Many tables may not meet our own business requirements. You can use the following custom methods:
1. Use the Authenticate event of the Login Control
This event is used for verification and can be verified by specifying the true value:
Protected void login=authenticate (object sender, AuthenticateEventArgs e)
{
// Determine whether the user name and password are correct
//
E. Authenticated = true;
} 2. Write the code by yourself, regardless of the Login and other controls.
In fact, the core of the Login control is to put some values into the Cookie, so we can perform this operation in our own code:
Protected void button#click (object sender, EventArgs e)
{
// Determine whether the user name and password are correct
//.
FormsAuthentication. SetAuthCookie (userName, false );
If (Context. Request ["ReturnUrl"]! = Null)
{
Response. Redirect (Context. Request ["ReturnUrl"]);
}
Else
{
Response. Redirect (FormsAuthentication. DefaultUrl );
}
} You do not need to create a default database using the above two methods. You can directly use our logic for verification.

3. Custom role providers
All of the above are user-level authentication. In some cases, it is necessary to verify based on the role. For example, specifying a directory or An aspx file can only be accessed by users of which roles, it is more convenient and flexible to Control Based on roles.
1. Save the role information to the Cookie during login verification:
Protected void button#click (object sender, EventArgs e)
{
// Determine whether the user name and password are correct
//.

// Get the role of the user, and write it to death temporarily during the test
String userRoles = "Admins, testst ";
FormsAuthenticationTicket Ticket = new FormsAuthenticationTicket (1, user, DateTime. Now, DateTime. Now. AddMinutes (30), false, userRoles ,"/");
String HashTicket = FormsAuthentication. Encrypt (Ticket );

// Save the role information to the Cookie
HttpCookie UserCookie = new HttpCookie (FormsAuthentication. FormsCookieName, HashTicket );
Response. Cookies. Add (UserCookie );

If (Context. Request ["ReturnUrl"]! = Null)
{
Response. Redirect (Context. Request ["ReturnUrl"]);
}
Else
{
Response. Redirect (FormsAuthentication. DefaultUrl );
}
} Encrypt the role information and save it in a specific format.
2. Custom role providers
If you want to verify by role, it must involve the role provider. By default, it will connect to the default database, we can write a role provider to implement our own logic.
First, add the configuration in web. config:
Code
Enabled = "true"
CacheRolesInCookie = "true"
CookieName = ". ASPROLES"
CookieTimeout = "30"
CookiePath = "/"
CookieRequireSSL = "false"
CookieSlidingExpiration = "true"
CookieProtection = "All">


Type = "MyRoleProvider"
WriteExceptionsToEventLog = "false"/>

This is to specify the class MyRoleProvider provided by our role.
This class must be inherited from System. Web. Security. RoleProvider. You only need to implement a method by reloading it (Other Methods return exceptions ):
Public override string [] GetRolesForUser (string username)
{
FormsIdentity Id = HttpContext. Current. User. Identity as FormsIdentity;
If (Id! = Null)
{
Return Id. Ticket. UserData. Split (new Char [] {','});
}
Return null;
} That is, the User role is obtained from the value previously saved to the Cookie (FormsAuthentication automatically converts the saved cookie to the value in the User)