SEGURO tipo de codificación

Question

Cuando empecé en desarrollo de aplicaciones web que contienen sus datos de autenticación de usuario en dos variables de sesión

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

Pero alguien me propuso la idea de crear una clase que contiene el nombre y contraseña propiedades y la autenticación exitosa Se me ha pedido para crear una instancia de la clase y establecer las propiedades y tienda de usuario y contraseña que instancia en la sesión.

Me han dicho que el objeto de sesión es Typesafe. ¿Puede alguien explicar lo que es typesafe la codificación y la ventaja de almacenar el objeto de la sesión.

Answer 1

Básicamente, el enfoque clásico de almacenar valores directamente en Session["something"] tiene dos inconvenientes:

• cuerdas mágicas . Si escribe mal something, su código compila bien, pero se obtiene ya sea un error de ejecución o, peor, un error inadvertido en el código
• casting : Después de leer Session["something"], necesita para su emisión al tipo que necesita. (Esto es lo que se entiende por "no de tipo seguro" ).

El uso de un objeto inflexible de tipos que se almacena en la Sesión eliminó el segundo problema. Bueno, en realidad, el objeto personalizado todavía tiene que ser fundido, pero es sólo un molde en lugar de dos moldes (o diez), lo que reduce la likelyhood de que algo va mal. Una vez más, un elenco mal es algo que sólo se detecta en tiempo de ejecución.

Otro enfoque consiste en encapsular el acceso a las variables de sesión en las propiedades estáticas:

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

Por supuesto, ambos enfoques pueden combinarse, lo que le permite a las propiedades relacionadas con grupo (usuario y contraseña) en un objeto común.

Answer 2

Tener una clase de usuario con 2 campos puede ser bueno por muchas razones, como para la seguridad de tipos, si alguna vez el tipo de sesión [ "Pasword"] en algún lugar obtendrá un error que no será tan fácil de encontrar, se tiene que comprobar si los dos nombres de los parámetros en todas partes. Es necesario que sean correctas, y es una gran fuente de errores. Una vez que almacena objeto Usuario en lugar de 2 cadenas inconexas habrá poder utilizar escribir código seguro como user.password lugar de tratar de contraseña de acceso de indexador cadena en la sesión. Además, si su usuario alguna vez se pone más campos, lo cual es muy común que se simplemente añadirlos a la clase de usuario, se inicia la creación de nuevos parámetros y los nombres y almacenarlos en el montón de sesión.

En cuanto a la seguridad de tipos de codificación Creo http://en.wikipedia.org/wiki/Type_safety debería ayudar, o cualquier otro tipo de artículo sobre el tema, que es muy popular que pienso.

Además no creo que usted debe guardar la contraseña en la sesión, depende de la lógica del programa, pero por lo general la contraseña sólo se debe utilizar para calcular el hash MD5 y nunca deberá utilizarse a continuación.

Answer 3

Pues estás amigo es un medio adecuado, pero no creo que la sesión se escriba intrínsecamente seguro. La sesión de recogida almacena instancias de objetos. Lo que puede almacenar una instancia de cualquier tipo (una cadena, un entero, o una clase de login personalizado), ya que todos se derivan de objeto. Sin embargo, al recuperar ese objeto, no se sabe de qué tipo es, y la necesidad de cuidado lanzas, con el manejo de excepciones, antes de usarla. por ejemplo, esto funciona bien:

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

Sin embargo, usted podría tratar de hacer lo siguiente, lo que provocará errores.

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

Para evitar esto, se tendría que hacer lo siguiente:

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

Tener un objeto de inicio de sesión personalizado resuelve ligeramente este problema, ya que sólo tendría un objeto a preocuparse, y un elenco de hacer. También podría extender el objeto de inicio de sesión fácilmente con la información adicional, y aún así no tener que hacer nada más moldes.