Typ Sichere Codierung

Question

Wenn ich die Entwicklung von Web-Anwendungen beginne ich die Authentifizierungsdaten des Benutzers in zwei Session-Variablen gespeichert

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

Aber jemand vorgeschlagen mir eine Idee, eine Klasse zu erstellen, die die Benutzername und Passwort Eigenschaften und auf erfolgreiche Authentifizierung hält habe ich gebeten worden, eine Instanz der Klasse zu erstellen und die Benutzername und das Passwort Eigenschaften und speichert diese Instanz in der Sitzung.

Ich habe gesagt, dass das Sitzungsobjekt ist typsicher. Kann jemand erklären, was in der Sitzung typsichere Codierung und den Vorteil der Speicherung des Objekts ist.

Answer 1

Grundsätzlich ist der klassische Ansatz der Werte direkt in Session["something"] Speicherung hat zwei Nachteile:

• Magie Strings . Wenn Sie something vertippen, Ihr Code kompiliert in Ordnung, aber Sie bekommen entweder einen Laufzeitfehler oder, schlimmer noch, ein unbemerkter Fehler im Code
• Casting : Nach Session["something"] lesen, müssen Sie es auf die Art werfen Sie benötigen. (Dies ist, was gemeint ist mit "nicht typsicher" ).

Mit einem stark typisierte Objekt, das in der Session gespeichert wird, eliminierte das zweite Problem. Nun, eigentlich Ihr benutzerdefiniertes Objekt muss noch gegossen werden, aber es ist nur eine Besetzung statt zwei (oder zehn) Abgüsse, die die Wahrscheinlichkeit von etwas schief gehen reduziert. Auch hier ist eine falsche Besetzung etwas, das nur zur Laufzeit erkannt wird.

Ein weiterer Ansatz ist es, den Zugriff auf Session-Variablen in statischen Eigenschaften zu kapseln:

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

Natürlich können beide Ansätze kombiniert werden, so dass Sie, um verwandte Eigenschaften (Benutzername und Passwort) in einem gemeinsamen Objekt.

Answer 2

eine User-Klasse mit 2 Felder Mit gut aus vielen Gründen sein kann, wie bei Typ Sicherheit, wenn Sie jemals Session geben [ „Pasword“] irgendwo wird eine Fehlermeldung angezeigt, die so leicht zu finden sein werde nicht, müssen Sie Check für beide Parameternamen überall. Sie müssen sie Fehler korrigieren, und es ist eine große Quelle sein. Sobald Sie Benutzerobjekt speichern, anstatt von 2 unverbundenen Saiten haben Sie in der Lage sein, sicher Code wie User.Password zu verwenden, geben Sie anstelle von String-Indexer in Session zu Zugangspasswort zu versuchen. Auch wenn Ihre Benutzer immer mehr Felder bekommen, die sehr häufig sind, werden Sie einfach fügen Sie sie auf User-Klasse, nicht starten neue Parameter & Namen erstellen und speichern sie in Session Haufen.

Wie für typsichere Codierung Ich denke, http://en.wikipedia.org/wiki/Type_safety sollte, oder jede andere Art von Artikel zum Thema helfen, die sehr beliebt ist, denke ich.

Auch ich denke, müssen Sie nicht das Kennwort in der Sitzung gespeichert werden sollte, hängt von Ihrer Programmlogik aber in der Regel Passwort sollte nur verwendet werden, um seine MD5-Hash zu berechnen und danach nie verwendet werden.

Answer 3

Nun, du bist Freund ist halb rechts, aber ich glaube nicht, Session inhärent sicher ist, ein. Die Session Sammlung speichert Instanzen von Object. So können Sie eine Instanz von jeder Art (eine Zeichenfolge, ein int oder einer Login-Klasse custom) speichern können, weil sie alle von dem Objekt abzuleiten. Wenn Sie jedoch das Objekt abzurufen, wissen Sie nicht, welche Art es ist, und müssen sorgfältig gegossen es, mit Ausnahmebehandlung, bevor Sie es benutzen. zB das funktioniert gut:

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

Allerdings könnten Sie versuchen, die folgenden zu tun, was zu Fehlern führen wird.

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

Um dies zu umgehen, müßten Sie folgendes tun:

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

Nachdem ein benutzerdefinierte Login-Objekt löst dieses Problem leicht, weil man nur über ein Objekt zu kümmern würde, und einen Guss zu machen. Sie könnten auch das Login-Objekt leicht mit zusätzlichen Informationen erweitern und haben noch keine mehr Würfe zu tun.