Con el lanzamiento de AJAX.NET BETA 2 hoy, hemos visto cuán rápida y eficiente es la estrecha integración de AJAX y ASP.NET 2.0. Incluso podemos hacer que las páginas web ASP.NET sean más eficientes sin escribir un solo código JS. Efecto gratuito logrado con horas de código JS escrito. Es muy fácil integrar todo esto en ASP.NET. Sólo necesita mover el control al control UPDATEPANEL y configurar algunos parámetros. Sin embargo, mientras experimenta la conveniencia que AJAX.NET brinda a los desarrolladores, también encontrará que AJAX.NET a veces no es perfecto. Al igual que el autor encontró recientemente un error en el control de inicio de sesión de ASP.NET 2.0 que actualiza la página después de verificar con éxito la información del usuario en UPDATEPANEL. Obviamente, esto viola el principio de no actualización de AJAX. El método de verificación de información de identidad encontró el siguiente código:
private void AttemptLogin()
{
LoginCancelEventArgs args1 = nuevo LoginCancelEventArgs();
this.OnLoggingIn(args1);
si (!args1.Cancelar)
{
AuthenticateEventArgs args2 = nuevo AuthenticateEventArgs();
this.OnAuthenticate(args2);
si (args2.Autenticado)
{
//Una vez verificada correctamente la información del usuario, escriba la información de la COOKIE para el cliente.
FormsAuthentication.SetAuthCookie(this.UserNameInternal, this.RememberMeSet);
this.OnLoggedIn(EventArgs.Empty);
//Es la siguiente declaración de respuesta la que causa problemas. Realizar una operación de redirección en el control UPDATEPANEL hace que la página se actualice.
this.Page.Response.Redirect(this.GetRedirectUrl(), falso);
}
}
}
Al analizar el método AttemptLogin, no es difícil ver que cuando presionamos el botón de inicio de sesión del control de inicio de sesión y verificamos con éxito la información del usuario, se ejecutará una declaración de redirección de página Response.Redirect (este código se ejecutará incluso si la redirección La página no está especificada y la predeterminada es la página actual), y es precisamente debido a la redirección de la página que la página se actualiza. Una vez que conozca la causa del error, será más fácil de manejar. Tal vez alguien diga que el control personalizado puede heredar el control de inicio de sesión y anular el método AttemptLogin, pero ¿existe una forma más sencilla además de los controles personalizados? La respuesta es sí. Dado que es el mecanismo de verificación incorporado el que hace que la página se actualice, simplemente no use el procesamiento de verificación del control de inicio de sesión, sino use un método personalizado para manejar la verificación de la identidad del usuario. Primero, para usar un método de verificación personalizado, primero buscamos el control Login y lo convertimos en una plantilla. Luego buscamos el control LoginButton en la plantilla y eliminamos CommandName="Login" para que el control ya no use el método integrado. en el método de verificación Ahora que tenemos información del usuario, agreguemos un evento OnClick a LoginButton.
void protegido LoginButton_Click (remitente del objeto, EventArgs e)
{
//Verifica si el nombre de usuario y la contraseña son correctos
if (Membresía.ValidarUsuario(Inicio de sesión1.Nombre de usuario, Inicio de sesión1.Contraseña))
{
// Según el análisis anterior del mecanismo de verificación de inicio de sesión, escriba COOKIE para el cliente.
FormsAuthentication.SetAuthCookie(Inicio de sesión1.Nombre de usuario, Inicio de sesión1.RememberMeSet);
// Después de una verificación exitosa, puede realizar algunos procesamientos aquí, como ocultar el control de inicio de sesión.
Iniciar sesión1.Visible = falso;
}
demás
{
// Dado que no se utiliza el mecanismo de verificación incorporado, usted mismo debe configurar el manejo de fallas de verificación.
(Login1.FindControl("FailureText") as Literal).Text = "El nombre de usuario o la contraseña son incorrectos, ¡inténtelo de nuevo!";
}
}
Analice el código anterior La información del usuario que será verificada por el control de inicio de sesión se almacena en la tabla aspnet_membership de la base de datos Aspnetdb de SQL2005. De esta manera, podemos verificar fácilmente la información del usuario utilizando el método Membership.ValidateUser. la verificación es exitosa, siga el análisis anterior. El método AttemptLogin escribe COOKIE para el cliente y luego establece el mensaje de error para la verificación fallida. Luego podemos transformar fácilmente nuestro control de inicio de sesión para que ya no se actualice después de verificar con éxito la información del usuario. es que no es necesario escribir personalizado El control es tan complejo como el control de inicio de sesión original y el efecto es exactamente el mismo que el control de inicio de sesión original. El nombre de usuario creado por el control CreateUserWizard aún se puede usar para verificación y controles. relacionados con el control de inicio de sesión, como LoginStatus y LoginName, también se pueden utilizar como de costumbre.
PD: si se produce una excepción PageRequestManagerParserErrorException cuando el control de inicio de sesión verifica la información del usuario, verifique si web.config contiene esta oración:
<httpMódulos>
.....
<add name="ScriptModule" type="Microsoft.Web.UI.ScriptModule, Microsoft.Web.Extensions, Versión=1.0.61025.0, Cultura=neutral, PublicKeyToken=31bf3856ad364e35"/>
</httpModules>
Gracias platillo por recordarnos
http://www.cnblogs.com/aspxcn/archive/2006/11/07/552927.html