Solution to the problem of page refresh in Login control after successfully verifying user information in UpdatePanel

With the release of AJAX.NET BETA 2 today, we have seen how fast and efficient the close integration of AJAX and ASP.NET 2.0 is. We can even make ASP.NET web pages more efficient without writing a single JS code. Refresh-free effect achieved with hours of JS code written. It is so easy to integrate all this into ASP.NET. You only need to simply move the control into the UPDATEPANEL control and set a few parameters. However, while experiencing the convenience that AJAX.NET brings to developers, you will also find that AJAX.NET is sometimes not perfect. Just like the author recently encountered a bug in the ASP.NET 2.0 Login control that refreshes the page after successfully verifying user information in UPDATEPANEL. Obviously this violates the principle of AJAX no refresh. After analyzing the user information built into the Login control, The method of identity information verification found the following code:

private void AttemptLogin()
{
LoginCancelEventArgs args1 = new LoginCancelEventArgs();
this.OnLoggingIn(args1);
if (!args1.Cancel)
{
AuthenticateEventArgs args2 = new AuthenticateEventArgs();
this.OnAuthenticate(args2);
if (args2.Authenticated)
{
//After the user information is successfully verified, write COOKIE information for the client.
FormsAuthentication.SetAuthCookie(this.UserNameInternal, this.RememberMeSet);
this.OnLoggedIn(EventArgs.Empty);

//It is the following Response statement that causes trouble. Performing a redirection operation in the UPDATEPANEL control causes the page to refresh!
this.Page.Response.Redirect(this.GetRedirectUrl(), false);
}
}
}

By analyzing the AttemptLogin method, it is not difficult to see that when we press the login button of the Login control and successfully verify the user information, a Response.Redirect page redirection statement will be executed (this code will be executed even if the redirection page is not specified, and the default is the current page) , and it is precisely because of the page redirection that the page is refreshed. Once you know the cause of the error, it will be easier to handle. Maybe someone will say that the custom control can inherit the Login control and override the AttemptLogin method. But is there an easier way besides custom controls? The answer is yes. Since it is the built-in verification mechanism that causes the page to refresh, then simply do not use the verification processing of the Login control, but use a custom method to handle the verification of the user's identity. First, in order to use a custom verification method, we first find the Login control and convert it into a template. Then we find the LoginButton control in the template and remove CommandName="Login" so that the control no longer uses the built-in method for verification. Now that we have user information, let’s add an OnClick event to LoginButton. The code is as follows:

protected void LoginButton_Click(object sender, EventArgs e)
{
//Verify whether the username and password are correct
if (Membership.ValidateUser(Login1.UserName, Login1.Password))
{
//According to the above analysis of Login verification mechanism, write COOKIE for the client.
FormsAuthentication.SetAuthCookie(Login1.UserName, Login1.RememberMeSet);
//After successful verification, you can do some processing here, such as hiding the Login control.
Login1.Visible = false;
}
else
{
//Since the built-in verification mechanism is not used, the handling of verification failure needs to be set up by yourself.
(Login1.FindControl("FailureText") as Literal).Text = "The username or password is incorrect, please try again!";
}
}

Analyze the above code. The user information to be verified by the Login control is stored in the aspnet_membership table of the Aspnetdb database of SQL2005. In this way, we can easily verify the user information by using the Membership.ValidateUser method. When the verification is successful, follow the above analysis The AttemptLogin method writes COOKIE for the client, and then sets the error message for verification failure. Then we can easily transform our Login control to no longer refresh after successfully verifying user information. The advantage of this transformation is that there is no need to write custom The control is as complex as the original Login control, and the effect is exactly the same as the original Login control. The user name created by the CreateUserWizard control can still be used for verification, and controls related to the Login control such as LoginStatus and LoginName can also be used as usual.

PS: If a PageRequestManagerParserErrorException occurs when the Login control verifies user information, please check if web.config contains this sentence:

.....

Thanks saucer for reminding

http://www.cnblogs.com/aspxcn/archive/2006/11/07/552927.html