Type de sécurité codage

Question

Quand j'ai commencé à développer des applications web i stockées les informations d'authentification de l'utilisateur dans deux variables de session

 Session["UserName"]="username";
 Session["Password"]="paswword-123";

Mais quelqu'un m'a proposé une idée de créer une classe qui détient les propriétés UserName et mot de passe et l'authentification succesful m'a demandé de créer une instance de la classe et définissez les propriétés UserName et mot de passe et de stocker cette instance dans la session.

J'ai été dit que l'objet de la session est Typesafe. Quelqu'un peut-il expliquer ce qui est typesafe le codage et l'avantage de stocker l'objet dans la session.

Answer 1

En fait, l'approche classique de stockage de valeurs directement dans Session["something"] présente deux inconvénients:

• chaînes magiques :. Si vous something faute de frappe, votre code compile bien, mais vous obtenez soit une erreur d'exécution ou, pire, un bug inaperçu dans votre code
• Castings : Après avoir lu Session["something"], vous devez jeter le type dont vous avez besoin. (C'est ce que l'on entend par "pas de type-safe" .)

L'utilisation d'un objet fortement typé qui est stocké dans la session a éliminé le deuxième problème. Eh bien, en fait, votre objet personnalisé doit encore être lancé, mais il est seulement un casting au lieu de deux moulages (ou dix), ce qui réduit la probabilité de quelque chose de mal va. Encore une fois, une mauvaise distribution est quelque chose qui n'est détecté lors de l'exécution.

Une autre approche consiste à encapsuler l'accès à des variables de session dans les propriétés statiques:

public class MySession {
    public static string UserName {
        get { return (string)HttpContext.Current.Session["UserName"]; }
        set { HttpContext.Current.Session["UserName"] = value; }
    }
}

Bien sûr, les deux approches peuvent être combinées, vous permettant de propriétés liées au groupe (et mot de passe) UserName dans un objet commun.

Answer 2

Avoir une classe d'utilisateurs avec 2 champs peut être bon pour de nombreuses raisons, comme pour la sécurité de type, si jamais vous tapez session [ « Pasword »] quelque part, vous obtiendrez une erreur qui ne sera pas en si facile à trouver, vous devrez vérifier les noms des paramètres partout. Vous avez besoin d'être correct, et son une grande source d'erreurs. Une fois que vous stockez objet utilisateur au lieu de 2 chaînes non connectées, vous avez en mesure d'utiliser le code de type sûr comme user.password au lieu d'essayer de mot de passe d'accès par indexeur chaîne en session. Aussi, si votre utilisateur obtient toujours plus de champs, ce qui est très commun, vous simplement les ajouter à la classe utilisateur, pas commencer à créer de nouveaux paramètres et les noms et les stocker dans tas session.

En ce qui concerne le codage typesafe Je pense que http://en.wikipedia.org/wiki/Type_safety devrait aider, ou tout autre type d'article sur le sujet qui est très populaire, je pense.

Aussi je ne pense pas que vous devriez stocker le mot de passe en session, dépend de votre logique de programme, mais généralement le mot de passe ne doit être utilisé pour calculer le hachage md5 et ne jamais être utilisé par la suite.

Answer 3

Eh bien, vous êtes la moitié ami est juste, mais je ne crois pas que la session est de type à sécurité intrinsèque. Les instances de magasins de collecte session de l'objet. Ainsi, vous pouvez stocker une instance de tout type (une chaîne, un int, ou une classe de connexion personnalisée) car ils dérivent tous de l'objet. Cependant, lorsque vous reprendrez cet objet, vous ne savez pas quel type il est, et la nécessité de soigneusement lancez, avec la gestion des exceptions, avant de l'utiliser. par exemple, cela fonctionne correctement:

Session["UserName"] = "Freddy";
string theUserName = (string)Session["UserName"];

Cependant, vous pouvez essayer de faire ce qui suit, ce qui entraînera des erreurs.

Session["UserName"] new StrangeDataClass(); //Uh Oh, that's not a string.
string theUserName = (string)Session["UserName"]; //unexpected behaviour based on StrangeDataClass.ToString() implementation.

Pour éviter cela, vous auriez à faire ce qui suit:

string theUserName = Session["UserName"] as string;
if (string != null)
    //The cast worked...
else
    //The cast failed, (or the string stored in session was null)

Avoir un objet de connexion personnalisée résout légèrement ce problème, parce que vous ne souhaitez avoir un objet à craindre, et un casting à faire. Vous pouvez également étendre l'objet de connexion facilement avec des informations supplémentaires, et toujours pas plus à faire des moulages.