Как синхронизировать время жизни cookie проверки подлинности форм и сеанса Asp.Net?

Я создаю веб-сайт ASP.NET, который использует FormsAuthentication и стандартный механизм сеанса с такой конфигурацией, как:

<authentication mode="Forms">
    <forms cookieless="UseCookies" name=".MyAppAuth" loginUrl="~\Login.aspx" timeout="20"/>
</authentication>
...
<sessionState timeout="20" cookieless="UseCookies" />

Кажется, что время жизни cookie аутентификации не равно времени жизни пользовательского сеанса. Итак, ASP.NET не гарантирует, что

  1. Сеанс завершается при выходе пользователя из системы,

  2. Сессия не завершается до выхода пользователя из системы.

Есть ли способ настроить FormsAuthentication или \ и механизм состояния сеанса для достижения этих целей?


security asp.net session forms-authentication
person Alexander K.    schedule 19.05.2009    source источник

Ответы (3)


arrow_upward
6
arrow_downward

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

По истечении срока действия cookie аутентификации на сервере ничего не происходит. Нет отслеживаемого состояния.

У вас может быть ссылка «выход» и в обработчике Abandon сеанс и SignOut из FormsAuthentication, но нет ничего, что заставляло бы пользователя выйти с веб-сайта.

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

По возможности избегайте использования сеанса, а если его необходимо использовать, соблюдайте рекомендации в статье MSDN Повышение производительности ASP.NET. Также ознакомьтесь с Общие сведения о режимах состояния сеанса + FAQ и, в частности, В. Почему не запускается Session_End?

person Robert Paulson    schedule 19.05.2009

arrow_upward
10
arrow_downward

Я слышал этот вопрос много раз, мой ответ обычно «зачем вам это?». Одно не требует другого, и срок их годности должен определяться с использованием разных критериев.

Состояние сеанса не требует от пользователя входа в систему. Приложению даже не нужно использовать аутентификацию, чтобы использовать состояние сеанса. У вас может быть веб-приложение, в котором пользователь уже использует состояние сеанса еще до входа в систему и продолжает использовать его после выхода. «Сеанс» здесь - это когда клиент (веб-браузер) подключается к сайту, прыгает по нескольким страницам и уходит. Не имеет значения, вошел ли пользователь в систему или нет. Если вы закроете браузер, откроете новый и вернетесь на сайт, будет создан новый сеанс. Но сервер не знает, что вы закрыли старое окно браузера, поэтому исходный сеанс все еще существует. В целях масштабируемости (в основном памяти) мы завершаем наши сеансы и освобождаем его память и ресурсы отслеживания сеансов. Если клиенту требуется слишком много времени, чтобы сделать новый запрос, новый запрос создаст новый сеанс.

С другой стороны, вы можете использовать аутентификацию и вообще не использовать состояние сеанса. Обычно я запускаю свои приложения с отключенным состоянием сеанса и состоянием просмотра и включаю их только в случае необходимости и постранично (или «контроль за контролем» для состояния просмотра).

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

Аутентификация сохраняется в виде файла cookie на клиенте и в основном не потребляет никаких ресурсов сервера. С точки зрения масштабируемости срок действия входа в систему обычно может быть больше, чем срок действия сеанса. Фактически, пользователь может оставаться в системе неограниченное время. Когда срок аутентификации сокращается, это обычно делается из соображений безопасности. Вы же не хотите, чтобы ваш банковский счет на веб-сайте был доступен кому-то еще, если вы отойдете от компьютера на 15 минут, верно? Вы можете войти в Gmail или Facebook и выбрать «запомнить меня» и вернуться через несколько дней, и вы все еще вошли в систему. Но, конечно, это будет новый сеанс, потому что ни одно веб-приложение не должно удерживать данные сеанса за несколько дней.

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

person Lucas    schedule 20.05.2009

arrow_upward
4
arrow_downward

Причина, по которой я иногда задаю себе этот вопрос, заключается в том, чтобы предотвратить доступ к объектам сеанса с истекшим сроком действия. Когда сеанс истекает до истечения срока входа в систему, и пользователь запрашивает страницу, которая использует данные из сеанса, происходит неприятное исключение с нулевой ссылкой.

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

person Ashraf Sabry    schedule 21.05.2009