asp.net the form to verify the program

3. Create default.aspx and Login.aspx pages in the website
Put the login and CreateUserWizard controls in the Login.aspx page (because there is no user in our new library, the CreateUserWizard control is used to set up the test user, you can delete the control after you build the user)
Put some content in the Default.aspx page.
When we visit Default.aspx, we automatically turn to login.aspx for verification.

Two, the custom realization Way
The first approach will require the creation of a database, many tables that may not meet our own business requirements. You can use the following customization methods
1, the use of login control authenticate event
This event is used for validation by specifying a value of TRUE to indicate validation through:
protected void Login1_authenticate (object sender, AuthenticateEventArgs e)
{
Determine if the user name password is correct
//
E.authenticated = true;
}2, completely throw away login and other controls, write your own code
In fact, the core of the login control is mainly to put some values into the cookie, so we can do this in our own code:
protected void Button1_Click (object sender, EventArgs e)
{
Determine if the user name password is correct
//.
Formsauthentication.setauthcookie (UserName, false);
if (context.request["ReturnUrl"]!= null)
{
Response.Redirect (context.request["ReturnUrl"]);
}
Else
{
Response.Redirect (Formsauthentication.defaulturl);
}
In both of these ways, you do not have to set up a default database, directly using our logic for verification operations

Third, custom role providers
The above are all user-level authentication, in some cases need to be validated according to the role, such as the designation of a directory or an ASPX file can only have a few characters of the user access, according to the role of the control is more convenient and flexible.
1, in the login verification of the role information also saved to the cookie:
protected void Button1_Click (object sender, EventArgs e)
{
Determine if the user name password is correct
//.

The user's role, the test is temporarily written dead
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 in a 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 into a specific format to save.
2. Custom Role Providers
If you want to authenticate to the role, it is definitely about the role provider, and by default it will also connect to the default database, and 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 the designation of our role to provide class Myroleprovider.
This class must inherit from System.Web.Security.RoleProvider, as long as the overload implements one method (other methods return the exception):
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 we saved to the cookie before (FormsAuthentication automatically converts the saved cookie to the value in user)