Введите Безопасное Кодирование

Question

Когда я начал разрабатывать веб приложения, я сохранил данные аутентификации пользователя в двух переменных сеанса

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

Но кто-то предложил мне идею создать класс, который содержит свойства имени пользователя и пароля, и при успешной аутентификации меня попросили создать экземпляр класса и установить свойства имени пользователя и пароля и сохранить этот экземпляр в сеансе.

Мне сказали, что объект сеанса безопасен для типов.Кто-нибудь может объяснить, что такое типизированное кодирование и преимущество хранения объекта в сеансе.

Answer 1

По сути, классический подход заключается в хранении значений непосредственно в Session["something"] имеет два недостатка:

• Волшебные струны:Если вы неправильно наберете текст something, ваш код компилируется нормально, но вы получаете либо ошибку времени выполнения, либо, что еще хуже, незамеченную ошибку в вашем коде.
• Кастинг:После прочтения Session["something"], вам нужно привести его к нужному вам типу.(Это то, что подразумевается под "не типобезопасен".)

Использование строго типизированного объекта, который хранится в Сеансе, устранило вторую проблему.Ну, на самом деле, ваш пользовательский объект все еще нуждается в приведении, но это всего лишь одно приведение вместо двух (или десяти) приведений, что снижает вероятность того, что что-то пойдет не так.Опять же, неправильное приведение - это то, что обнаруживается только во время выполнения.

Другой подход заключается в инкапсуляции доступа к переменным сеанса в статических свойствах:

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

Конечно, оба подхода можно комбинировать, позволяя вам сгруппировать связанные свойства (имя пользователя и пароль) в общий объект.

Answer 2

Наличие пользовательского класса с 2 полями может быть хорошим по многим причинам, что касается безопасности типа, если вы когда-либо вводите сеанс [«Pasword»] где-то вы получите ошибку, что не будет так легко найти, вам придется проверить обоими имена параметров везде. Вам нужно, чтобы они были правильными, и это отличный источник ошибок. Как только вы храним пользовательский объект вместо 2 неоднократных строк, вы сможете использовать тип безопасного типа, например, user.password вместо того, чтобы пытаться получить доступ к паролю строкового индексатора в сеансе. Также, если ваш пользователь когда-либо получает больше полей, что очень распространено, вы просто добавите их в класс пользователей, не начнем создавать новые параметры и имена и хранить их в кучу сеанса.

Что касается кодирования Syplefefe, я думаю, http://en.wikipedia.org/wiki/type_safety Должна помочь, или любой другой тип статьи по теме, которая очень популярна, я думаю.

Кроме того, я не думаю, что вы должны хранить пароль в сеансе, зависит от логики программы, но обычно пароль следует использовать только для вычисления только HASH MD5 и никогда не использоваться впоследствии.

Answer 3

Ну, ты друг наполовину верно, но я не верю, что сеанс по своей природе входит в безопасном. Сборник сеансов хранит экземпляры объекта. Таким образом, вы можете хранить экземпляр любого типа (строка, int или пользовательский класс входа в систему), потому что все они получают от объекта. Тем не менее, когда вы извлекаете этот объект, вы не знаете, какой это тип, и нужно тщательно отбрасывать его, с обработкой исключения, прежде чем использовать его. например, это работает нормально:

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

Однако вы можете попытаться сделать следующее, что вызовет ошибки.

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

Работать вокруг этого, вам придется сделать следующее:

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

Наличие пользовательского объекта входа в систему, слегка решает эту проблему, потому что у вас только один объект, о которых можно беспокоиться, и один лишать. Вы также можете легко продлить объект входа в систему с дополнительной информацией, и все еще не приходится делать больше каст.