2010-10-30 24 views
1

J'ai une page .aspx qui contient un contrôle Web <asp:Login>.Les événements de contrôle Web de connexion ASP ne se comportent pas comme prévu

Pour l'authentification, j'ai une autre classe (MyMembershipProvider) qui hérite de la classe System.Web.Security.MembershipProvider. Le processus de connexion fonctionne correctement: le nom d'utilisateur/mot de passe est correctement authentifié par l'objet MyMembershipProvider.

Ma question concerne les paramètres System.Web.SessionState.HttpSessionState.Session.

Après qu'un utilisateur a été authentifié avec succès (par la classe MyMembershipProvider), je voudrais créer Session vars personnalisé pour cet utilisateur.

Au départ, je pensais que je serais en mesure de définir les Session variables dans le gestionnaire d'événements de contrôle <asp:Login>LoggedIn - quelque chose comme ceci:

protected void LoginUser_LoggedIn(object sender, EventArgs e) 
{ 
    //Get the UserName of the authenticated user 
    string userName = Thread.CurrentPrincipal.Identity.Name; 

    //Call the business layer to get more info on the authenticated user 
    Entities.User user = BizLayer.GetUser(userName); 

    //Set session vars for the authenticated user 
    Session["LastName"] = user.LastName; 
    Session["FirstName"] = user.FirstName; 
    Session["Email"] = user.Email; 
} 

Le problème que je remarque est que lorsque l'événement LoggedIn est tiré le Thread.CurrentPrincipal.Identity.Name n'a pas encore été défini sur le nom d'utilisateur utilisé lorsque l'utilisateur s'est connecté. Par conséquent, l'appel au BizLayer.GetUser() renvoie un objet User vide, ce qui, bien sûr, rend les setters Session inutilisables.

Je pense que depuis que je suis en utilisant une coutume MembershipProvider, les gestionnaires d'événements <asp:Login> (LoggedIn, Authenticated, LoggingIn) ne fonctionnent pas comme je les attendais à.

Existe-t-il un autre gestionnaire d'événements que je devrais utiliser pour définir les variables Session? Ou, pouvez-vous me pointer dans la bonne direction qui accomplirait la même chose que je décris?

Jusqu'à ce que j'entends parler d'une meilleure façon, j'ai mis en œuvre les éléments suivants:

j'ai changé l'attribut DestinationPageUrl du contrôle <asp:Login> à pointer vers une page qui fera le travail de réglage des Session vars. Ensuite, après avoir défini les vars Session, j'appelle Response.Redirect() pour aller à la page qui était précédemment définie dans l'attribut DestinationPageUrl.

Le code pertinent ressemble à ceci:

Login.aspx page Web a un contrôle de connexion similaire à ...

<asp:Login ID="LoginUser" runat="server" DestinationPageUrl="SetSessionVars.aspx"> 

SetSessionVars.aspx page Web a une méthode qui définit la session vars et redirige l'utilisateur à une page ...

protected void Page_Load(object sender, EventArgs e) 
{ 
    this.SetSessionVars(); 
    Response.Redirect("foo.aspx"); 
} 

private void SetSessionVars() 
{ 
    //Get the UserName of the authenticated user 
    string userName = Thread.CurrentPrincipal.Identity.Name; 

    //Call the business layer to get more info on the authenticated user 
    Entities.User user = BizLayer.GetUser(userName); 

    //Set session vars for the authenticated user 
    Session["UserId"] = user.UserId; 
    Session["LastName"] = user.LastName; 
    Session["FirstName"] = user.FirstName; 
    Session["Email"] = user.Email; 
} 

Répondre

1

Pourquoi ne pas vous venez de capturer le nom d'utilisateur du formulaire de connexion au lieu de l'obtenir à partir Thread.CurrentPrincipal.Identity. Prénom?

L'ordre de ces choses dans ASP.NET n'est vraiment pas intuitif car l'identité est chargée avant Page_Load et n'est pas mise à jour lors de cet événement Logged_In comme prévu.Edit: puisque vous n'aimez pas cela, dans votre couche de gestion, vous voudrez ajouter quelque chose comme le ci-dessous.

var genericIdentity = new System.Security.Principal.GenericIdentity(username); 
HttpContext.Current.User = new System.Security.Principal.GenericPrincipal(genericIdentity, roles); 
+0

j'ai pensé qu'il valait mieux utiliser le .Identity.Name car il est une garantie que le nom d'utilisateur a été authentifié par la couche biz (MembershipProvider). Dans mon scénario, il n'est pas nécessaire de définir les variables de session si l'utilisateur n'a pas été authentifié. – Jed

+0

Assez juste, voir modifier. –