Вы звучите так, как будто вы «катите свою собственную» систему аутентификации.
Я хотел бы изучить использование встроенной в ASP.NET системы проверки подлинности с помощью форм , которая обычно используется с поставщиком членства ASP.NET . Встроенные поставщики уже существуют для SQL Server, и вы можете создать своего собственного поставщика членства, унаследовав базовый класс System.Web.Security.MembershipProvider .
По сути, поставщики членства в ASP.NET обычно работают, устанавливая куки-файл на стороне клиента (также известный как билет аутентификации) в браузере клиента, после того как клиент успешно аутентифицировался. Этот файл cookie возвращается на веб-сервер с каждым последующим запросом страницы, что позволяет ASP.NET и, следовательно, вашему коду определять, кто пользователь, обычно с помощью одной строки кода, например:
string username = HttpContext.Current.User.Identity.Name;
// The above gets the current user's name.
if(HttpContext.Current.User.Identity.IsAuthenticated)
// Do something when we know the user is authenticated.
Тогда вам не нужно ничего хранить в состоянии сеанса. Конечно, если вы хотите сохранить специфичные для пользователя данные в переменной сеанса (т. Е. Данные пользователя, которые могут не быть частью аутентификации пользователя, возможно, его любимый цвет и т. Д.), То всеми означает, что вы можете сохранить это в переменной сеанса (после извлечения ее из БД при первой аутентификации пользователя). Переменная сеанса может быть сохранена на основе имени пользователя (при условии уникальных имен) и получена с использованием кода, аналогичного приведенному выше, который получает имя текущего пользователя для доступа к правильному объекту сеанса.
Использование встроенной проверки подлинности форм также позволит вам «защитить» области вашего сайта от неавторизованных пользователей простым декларативным кодом, который содержится в вашем файле web.config, например:
<authorization>
<deny users="?"/>
</authorization>
Добавление вышеупомянутого в ваш "основной" файл web.config гарантирует, что ни одна из ваших страниц не будет доступна для неавторизованных пользователей (хотя вы, вероятно, никогда не сделаете этого на самом деле - это просто в качестве примера). Использование поставщика ролей ASP.NET совместно с поставщиком членства обеспечит вам еще большую детализацию в отношении того, кто может или не может получить доступ к различным разделам вашего веб-сайта.