Tipo di codificazione sicura

Question

Quando ho iniziato le applicazioni web in via di sviluppo ho conservato i dati di autenticazione degli utenti in due variabili di sessione

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

Ma qualcuno mi ha proposto l'idea di creare una classe che detiene l'UserName e le proprietà password e l'autenticazione di successo mi è stato chiesto di creare un'istanza della classe e impostare le proprietà e le memorizza il nome utente e la password che istanza nella sessione.

Mi è stato detto che l'oggetto sessione è Typesafe. Qualcuno può spiegare che cosa è typesafe la codifica e il vantaggio di memorizzare l'oggetto nella sessione.

Answer 1

In sostanza, il metodo classico di memorizzare valori direttamente in Session["something"] presenta due inconvenienti:

• corde magiche :. Se si digitano something, il codice compila bene, ma si ottiene sia un errore di runtime o, peggio, un bug inosservata nel codice
• Casting : Dopo aver letto Session["something"], è necessario cast al tipo di cui avete bisogno. (Questo è ciò che si intende per "Non type-safe" .)

Con un oggetto fortemente tipizzato che è memorizzato nella sessione eliminato il secondo problema. Beh, in realtà, il vostro oggetto personalizzato deve ancora essere lanciato, ma è solo un getto invece di due (o dieci) calchi, che riduce la probabilità che qualcosa vada storto. Anche in questo caso, un cast sbagliato è qualcosa che viene rilevato solo in fase di esecuzione.

Un altro approccio è quello di incapsulare l'accesso a variabili di sessione in proprietà statiche:

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

Naturalmente, entrambi gli approcci possono essere combinati, consentendo di proprietà correlate del gruppo (username e password) in un oggetto comune.

Answer 2

Avere una classe User con 2 campi può essere buono per molti motivi, come per la sicurezza tipo, se mai tipo di sessione [ "Pasword"] da qualche parte si otterrà un errore che non sarà così facile da trovare, si dovrà verificare la presenza di entrambi i nomi dei parametri ovunque. È necessario che siano corrette, e la sua una grande fonte di errori. Una volta che si memorizzano oggetto d'uso, invece di 2 stringhe non connessi avrete in grado di utilizzare digitare il codice di sicurezza come User.Password invece di cercare di password di accesso da indicizzatore stringa nella sessione. Anche se l'utente ottiene mai più campi, che è molto comune, si deve semplicemente aggiungerli alla classe utente, si avvia la creazione di nuovi parametri e nomi e li memorizza in mucchio di sessione.

Per quanto riguarda la codifica typesafe Penso http://en.wikipedia.org/wiki/Type_safety dovrebbe aiutare, o qualsiasi altro tipo di articolo sul tema che è molto popolare credo.

Anche io non credo che si dovrebbe memorizzare la password in sessione, dipende dalla vostra logica di programma, ma di solito la password deve essere utilizzato solo per calcolare il suo hash MD5 e mai essere utilizzati in seguito.

Answer 3

bene si sta amico è metà di destra, ma non credo di sessione è intrinsecamente SICURO tipo. I negozi di raccolta sessione istanze di oggetto. Così è possibile memorizzare un'istanza di qualsiasi tipo (una stringa, un int, o di una classe di login personalizzato) perché tutti derivano da oggetti. Tuttavia, quando si recuperano l'oggetto, non si sa che tipo è, e necessità di cura lanci, con la gestione delle eccezioni, prima di utilizzarlo. ad esempio, questo funziona bene:

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

Tuttavia si potrebbe provare a fare quanto segue, che causerà errori.

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

Per ovviare a questo, dovreste fare quanto segue:

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

Avere un oggetto di login personalizzato risolve un po 'questo problema, perché si avrebbe solo un oggetto di cui preoccuparsi, e un cast marca. Si potrebbe anche estendere l'oggetto di accesso facilmente con le informazioni supplementari, e ancora non hanno a che fare eventuali ulteriori calchi.