Digite codificação segura

Question

Quando comecei a desenvolver aplicações web armazenei os detalhes de autenticação do usuário em duas variáveis ​​de sessão

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

Mas alguém me propôs a ideia de criar uma classe que contenha as propriedades UserName e Password e, após autenticação bem-sucedida, fui solicitado a criar uma instância da classe e definir as propriedades UserName e Password e armazenar essa instância na sessão.

Disseram-me que o objeto de sessão é TypeSafe.Alguém pode explicar o que é codificação typesafe e a vantagem de armazenar o objeto na sessão.

Answer 1

Basicamente, a abordagem clássica de armazenar valores diretamente em Session["something"] tem duas desvantagens:

• Cordas mágicas:Se você digitar errado something, seu código será compilado corretamente, mas você receberá um erro de tempo de execução ou, pior, um bug despercebido em seu código.
• Fundição:Depois de ler Session["something"], você precisa convertê-lo para o tipo necessário.(Isso é o que se entende por "não é seguro para digitação".)

Usar um objeto fortemente tipado armazenado na Sessão eliminou o segundo problema.Bem, na verdade, seu objeto personalizado ainda precisa ser convertido, mas é apenas um lançamento em vez de dois (ou dez), o que reduz a probabilidade de algo dar errado.Novamente, uma conversão errada é algo que só é detectado em tempo de execução.

Outra abordagem é encapsular o acesso às variáveis ​​de sessão em propriedades estáticas:

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

É claro que ambas as abordagens podem ser combinadas, permitindo agrupar propriedades relacionadas (Nome de usuário e Senha) em um objeto comum.

Answer 2

Ter uma classe User com 2 campos pode ser bom por vários motivos, como por segurança de tipo, se você digitar Session["Password"] em algum lugar você receberá um erro que não será tão fácil de encontrar, você terá que verificar ambos nomes de parâmetros em todos os lugares.Você precisa que eles estejam corretos e isso é uma grande fonte de erros.Depois de armazenar o objeto User em vez de 2 strings desconectadas, você poderá usar um código de tipo seguro como User.Password em vez de tentar acessar a senha pelo indexador de string na sessão.Além disso, se o seu usuário obtiver mais campos, o que é muito comum, você simplesmente os adicionará à classe User, não começará a criar novos parâmetros e nomes e os armazenará no heap de sessão.

Quanto à codificação typesafe, eu acho http://en.wikipedia.org/wiki/Type_safety deveria ajudar, ou qualquer outro tipo de artigo sobre um tópico que seja muito popular, eu acho.

Além disso, não acho que você deva armazenar a senha na sessão, depende da lógica do seu programa, mas geralmente a senha só deve ser usada para calcular seu hash md5 e nunca mais ser usada depois.

Answer 3

Bem, seu amigo está meio certo, mas não acredito que Session seja inerentemente seguro.A coleção Session armazena instâncias de Object.Portanto, você pode armazenar uma instância de qualquer tipo (uma string, um int ou uma classe de login personalizada) porque todas elas derivam do objeto.No entanto, ao recuperar esse objeto, você não sabe de que tipo ele é e precisa lançá-lo cuidadosamente, com tratamento de exceções, antes de usá-lo.por exemplo, isso funciona bem:

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

No entanto, você pode tentar fazer o seguinte, o que causará erros.

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

Para contornar isso, você teria que fazer o seguinte:

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

Ter um objeto de login personalizado resolve um pouco esse problema, porque você teria apenas um objeto com o qual se preocupar e uma conversão para fazer.Você também pode estender o objeto de login facilmente com informações extras e ainda assim não precisar fazer mais conversões.