Это хорошая идея? Аутентифицировать пользователя в ASP.NET, установив переменную

Question

сеанса Для проверки подлинности пользователя в ASP.NET, я видел, как этот код

if (loginManager.Authenticate(username, password)) 
{ 
    Session["Authenticated"] = 1; 
} 

и в последующем запросе, просто проверить, является ли значение Session["Authenticated"] является 1, чтобы определить, аутентифицирован ли текущий пользователь.

Это очень просто. Мой вопрос: как это отличается от аутентификации ASP.NET Forms? - Создание файла проверки подлинности с использованием класса FormsAuthentication и определения того, аутентифицирован ли пользователь на основе поля User.Identity.IsAuthenticated?

Answer 1

Вы должны использовать проверку подлинности форм из-за нескольких причин:

1. Проверка подлинности форм была разработана Microsoft в течение многих лет. Его протестировали его сейф. Ваш метод никогда не тестировался, поэтому ни вы, ни я не можем быть уверены в том, что доверять его безопасной или нет, но проверяет подлинность.
2. Люди много борются с Сеансами, истекающими до времени.
3. С одновременным доступом пользователей к вашему сайту, использование сеанса приведет к проблемам с памятью.
4. Использование проверки подлинности форм является более чистым и более элегантным.
5. Почему бы не использовать подход, который используют многие разработчики, если завтра кто-то присоединяется к вашей команде и помогает в вашем проекте, он может ошибаться в вашей логике и может поставить под угрозу безопасность.

Answer 2

Аутентификация с использованием сеанса не является ни стандартом, ни хорошей практикой, поскольку сеансы идентифицируются с использованием SessionID, который устанавливается через класс FormsAuthentication. Этот класс заботится о поддержании привязки сеанса пользователя с сервером либо с помощью файлов cookie, либо если файлы cookie отключены, он переписывает URL-адрес пользователя для поддержания SessionID. Хотя сеанс может потеряться или скомпрометирован, механизм SessionID защищен шифрованием и проверкой на каждый запрос. Для этого аргумента есть много других причин. Короче говоря, я бы рекомендовал использовать стандартный способ.

Answer 3

Если сеанс cookie и истечение сеанса синхронизированы - вероятно, не будет никакой разницы. Но это не всегда так. Только один пример - вы сохраняете сеанс по умолчанию для ASP.NET - InProc. Но по какой-то причине процесс SessionState перезапускается, убивается, умирает, что угодно - все сеансы исчезли. Затем пользователь приходит на сайт - он имеет действительный файл cookie Auth и аутентифицируется. Но сеанс не может быть восстановлен, поэтому он воссоздается как новый (Session.IsNewSession = true). Таким образом, пользователь будет проверяться в соответствии с FormsAuthentication, но не будет иметь сессии [ «заверенного»] = 1 ...

Я нашел эту статью очень полезно по этому вопросу: http://www.abstraction.net/ViewArticle.aspx?articleID=74

Do у вас есть зависимость между токеном аутентификации пользователя и его сеансом?

В идеале ответ должен быть отрицательным. Вы не должны полагаться на данные сеанса, доступные для проблем, связанных с безопасностью, для многих причин , среди прочего, разделение проблем. Один токен касается прав доступа пользователей, а другой - для хранения пользовательских данных через запросы .Однако во многих случаях разработчики предпочитают хранить права доступа пользователя в сеансе, чаще всего на сайтах, которые позволяют анонимному и аутентифицированному доступу , причем у прошедших проверку подлинности пользователей есть дополнительных функций/страниц, доступных для них, а затем анонимных. Таким образом, вместо хранения токена прав доступа в аутентификации пользователя cookie разработчики предпочитают хранить права доступа пользователя на сеансе пользователя (иногда из-за того, что считается проблемой безопасности , однако это обычно ложное беспокойство, поскольку токен аутентификацииможет быть очень сильно зашифрован очень точно через атрибут защиты элемента forms в web.config). Но это предполагает, что сеанс не истекает до аутентификации - в противном случае вы останетесь с аутентифицированным пользователем , для которого вы фактически не знаете права доступа, так как те были сохранены в сеансе, который теперь ушел. Когда сталкиваются с этой зависимостью , многие разработчики считают, что достаточно установить сеанс тайм-аута на большее значение, чем время ожидания проверки подлинности, и установить значение slideExpiration равным true для проверки подлинности форм. Мысль заключается в том, что в этой настройке аутентификация пользователя истекает сначала, , заставляя ASP.Net автоматически обрабатывать это и перенаправлять пользователя на страницу входа (как указано в web.config). Если сеанс по-прежнему , он будет обновлен, если нет, будет создан новый, а затем права доступа пользователя будут установлены в соответствии с его именем пользователя.