Avec la sortie d'AJAX.NET BETA 2 aujourd'hui, nous avons vu à quel point l'intégration étroite d'AJAX et d'ASP.NET 2.0 est rapide et efficace. Nous pouvons même rendre les pages Web ASP.NET plus efficaces sans écrire un seul code JS. effet gratuit obtenu avec des heures de code JS écrit. Il est si simple d'intégrer tout cela dans ASP.NET. Il vous suffit de déplacer le contrôle dans le contrôle UPDATEPANEL et de définir quelques paramètres. Cependant, tout en profitant de la commodité qu'AJAX.NET apporte aux développeurs, vous constaterez également qu'AJAX.NET n'est parfois pas parfait. Tout comme l'auteur a récemment rencontré un bug dans le contrôle de connexion ASP.NET 2.0 qui actualise la page après avoir vérifié avec succès les informations utilisateur dans UPDATEPANEL. Évidemment, cela viole le principe de non-actualisation d'AJAX. Après avoir analysé les informations utilisateur intégrées au contrôle de connexion. La méthode de vérification des informations d'identité a trouvé le code suivant :
private void AttemptLogin()
{
LoginCancelEventArgs args1 = new LoginCancelEventArgs();
this.OnLoggingIn(args1);
si (!args1.Cancel)
{
AuthenticateEventArgs args2 = new AuthenticateEventArgs();
this.OnAuthenticate(args2);
si (args2.Authentifié)
{
//Une fois les informations utilisateur vérifiées avec succès, écrivez les informations COOKIE pour le client.
FormsAuthentication.SetAuthCookie(this.UserNameInternal, this.RememberMeSet);
this.OnLoggedIn(EventArgs.Empty);
//C'est l'instruction Response suivante qui provoque des problèmes. L'exécution d'une opération de redirection dans le contrôle UPDATEPANEL entraîne l'actualisation de la page !
this.Page.Response.Redirect(this.GetRedirectUrl(), false);
}
}
}
En analysant la méthode AttemptLogin, il n'est pas difficile de voir que lorsque nous appuyons sur le bouton de connexion du contrôle Login et vérifions avec succès les informations de l'utilisateur, une instruction de redirection de page Response.Redirect sera exécutée (ce code sera exécuté même si la redirection la page n'est pas spécifiée, et la page par défaut est la page actuelle), et c'est précisément à cause de la redirection de page que la page est actualisée. Une fois que vous connaîtrez la cause de l'erreur, elle sera plus facile à gérer. Peut-être que quelqu'un dira que le contrôle personnalisé peut hériter du contrôle Login et remplacer la méthode AttemptLogin. Mais existe-t-il un moyen plus simple que les contrôles personnalisés ? La réponse est oui. Puisque c'est le mécanisme de vérification intégré qui provoque l'actualisation de la page, n'utilisez tout simplement pas le processus de vérification du contrôle de connexion, mais utilisez une méthode personnalisée pour gérer la vérification de l'identité de l'utilisateur. Tout d'abord, afin d'utiliser une méthode de vérification personnalisée, nous trouvons d'abord le contrôle Login et le convertissons en modèle. Ensuite, nous trouvons le contrôle LoginButton dans le modèle et supprimons CommandName="Login" afin que le contrôle n'utilise plus le contrôle intégré. dans la méthode de vérification. Maintenant que nous avons les informations utilisateur, ajoutons un événement OnClick à LoginButton. Le code est le suivant :
protected void LoginButton_Click (expéditeur de l'objet, EventArgs e)
{
//Vérifie si le nom d'utilisateur et le mot de passe sont corrects
if (Membership.ValidateUser(Login1.UserName, Login1.Password))
{
//Selon l'analyse ci-dessus du mécanisme de vérification de connexion, écrivez COOKIE pour le client.
FormsAuthentication.SetAuthCookie(Login1.UserName, Login1.RememberMeSet);
//Après une vérification réussie, vous pouvez effectuer certains traitements ici, comme masquer le contrôle de connexion.
Connexion1.Visible = faux ;
}
autre
{
//Étant donné que le mécanisme de vérification intégré n'est pas utilisé, la gestion des échecs de vérification doit être configurée par vous-même.
(Login1.FindControl("FailureText") as Literal).Text = "Le nom d'utilisateur ou le mot de passe est incorrect, veuillez réessayer!";
}
}
Analysez le code ci-dessus. Les informations utilisateur à vérifier par le contrôle Login sont stockées dans la table aspnet_membership de la base de données Aspnetdb de SQL2005. De cette façon, nous pouvons facilement vérifier les informations utilisateur en utilisant la méthode Membership.ValidateUser. la vérification est réussie, suivez l'analyse ci-dessus. La méthode AttemptLogin écrit COOKIE pour le client, puis définit le message d'erreur pour l'échec de la vérification. Nous pouvons ensuite facilement transformer notre contrôle de connexion pour qu'il ne soit plus actualisé après avoir vérifié avec succès les informations de l'utilisateur. est qu'il n'est pas nécessaire d'écrire un contrôle personnalisé. Le contrôle est aussi complexe que le contrôle de connexion d'origine et l'effet est exactement le même que celui du contrôle de connexion d'origine. Le nom d'utilisateur créé par le contrôle CreateUserWizard peut toujours être utilisé pour la vérification et les contrôles. liés au contrôle de connexion tels que LoginStatus et LoginName peuvent également être utilisés comme d'habitude.
PS : si une PageRequestManagerParserErrorException se produit lorsque le contrôle de connexion vérifie les informations de l'utilisateur, veuillez vérifier si web.config contient cette phrase :
<Moduleshttp>
.....
<add name="ScriptModule" type="Microsoft.Web.UI.ScriptModule, Microsoft.Web.Extensions, Version=1.0.61025.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35"/>
</httpModules>
Merci soucoupe pour le rappel
http://www.cnblogs.com/aspxcn/archive/2006/11/07/552927.html