Тип безопасного кодирования

Question

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

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

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

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

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

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

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

Также я не думаю, что вы должны хранить пароль в сеансе, в зависимости от вашей логики программы, но обычно пароль должен использоваться только для вычисления хеша 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) 

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