Stockage des données utilisateur enregistrées

Question

En travaillant sur un projet MVC, l'utilisateur insère ses informations d'identification dans un formulaire de connexion. Je reçois tous les autres informations sur cet utilisateur par un webservice et je stocke actuellement comme ceci:

var result = client.getUser(gui); 
name = result.users.ElementAt(1).name; 
... 

... 

Session["userCode"] = userCode; 
Session["password"] = password; 
Session["userName"] = name; 
Session["userEmail"] = email; 
Session["creationDate"] = creationDate; 
Session["phoneNumber"] = phone; 

Tout au long de l'application, chaque fois que j'ai besoin, j'accéder à ces variables si j'ai besoin les données qu'ils contiennent. Puisque je travaille sur un nouveau projet qui ne contient que 5 pages, je me demande si je vais y accéder même si le projet a des dizaines de pages ou si je ne devrais pas utiliser de variables de session.

Existe-t-il un meilleur moyen de stocker ces données utilisateur enregistrées?

Answer 1

Commençons par le début: Ne stockez jamais le mot de passe de l'utilisateur dans une session - un problème de sécurité horrible!

Si vous développez votre application tout à l'heure, je recommande fortement d'utiliser Identity framework. Là, vous pouvez ajouter des revendications à l'identité de l'utilisateur. La liste des revendications est comme un dictionnaire de chaîne à chaîne. Et vous pouvez rechercher des réclamations quand vous le souhaitez.

Vous pouvez ajouter réclamation à l'utilisateur avec leur numéro de téléphone, e-mail et date de création facilement, alors les méthodes d'extension pour obtenir ces données sur:

public static bool GetEmail(this ClaimsPrincipal principal) 
{ 
    if (principal == null) 
    { 
     return false; 
    } 

    var emailClaim = principal.Claims.SingleOrDefault(c => c.Type == "Email"); 

    if (emailClaim == null) 
    { 
     return String.Empty; 
    } 
    return emailClaim .Value; 
} 

puis appeler cette méthode comme ceci:

ClaimsPrincipal.Current.GetEmail() 

Les revendications suivent l'utilisateur dans le cookie qui est chiffré.

UPD: vous ne devriez pas stocker de mot de passe en session car vous ne devriez pas en avoir besoin après l'authentification. Une fois l'utilisateur validé et le cookie d'authentification défini, vous devez supprimer le mot de passe de la mémoire. Si vous le gardez en session après l'authentification, il existe une situation où les données de session sont exposées l'un des scénarios auxquels je peux penser est l'exception stacktrace est déversée dans ELMAH, et ELMAH expose les variables de session en texte brut. Une autre situation est lorsque Glimpse est utilisé - il montre des données de session. En ce qui concerne l'aspect social de l'identité - vous pouvez ignorer tout cela en toute sécurité et créer votre application uniquement avec la liste interne des utilisateurs. Je viens de migrer l'un de mes projets de MembershipProvider vers Identity et je n'ai pris aucune dépendance sur l'authentification sociale. En ce qui concerne VS2010 (pourquoi ne pas mettre à niveau?), Identity ne dépend que d'Entity Framework 6.1, mais ne dépend pas de MVC ou d'autre chose, donc cela ne devrait poser aucun problème, sauf si vous utilisez Database First EF, dans ce cas, l'outillage EF6.1 pourrait ne pas fonctionner avec VS2010. Cependant, je n'ai pas essayé cela dans VS2010 et je vous suggère de créer un minuscule projet de test dans VS2010 qui simule l'intégration d'Identité avec votre site.