Post) ASP. NET Forms authentication (custom, role provider)

In the past, development projects often developed a set of user permission management systems for verification, which is flexible. Recently, I checked the self-built authentication method of ASP. net for the Single Sign-On problem, and found that this method is more convenient and the function is also available. In ASP. NET provides three common authentication methods: Windows and IIS can be combined to achieve basic, abstract, integrated windows and other authentication; passport uses Windows Live ID accounts for unified authentication. Forms use common forms for verification.

This article mainly discusses the Common Implementation of Forms authentication, custom implementation, user-defined role providers, and how to use single sign-on (can be combined with MOSS.

I. Common Implementation Methods
This method is the simplest. You only need to configure it.
1. Run the aspnet_regsql command to create a database.
The aspnet_regsql command is in the C:/Windows/Microsoft. NET/framework/v2.0.50727 directory. Run the command as prompted.

2. Create a web site
Add configuration in Web. config:

Enablepasswordretrieval = "false" enablepasswordreset = "true" requiresquestionandanswer = "true"
Requiresuniqueemail = "true" passwordformat = "hashed" name = "sqlprovider"
Type = "system. Web. Security. sqlmembershipprovider"/>

It mainly specifies the database used for Forms authentication. If no database is specified, the local default aspnetdb database will be used.
Deny users = "? "Indicates that anonymous users are not allowed to access the login. ASPX page configured below.
For details about other attributes in the authorization and authentication sections, refer to msdn.

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)

Then we can configure the role verification rules in Web. config:







Or you can judge in the Code:
Bool a = user. isinrole ("testt"); it is very convenient to judge.