Как работает тайм-аут сеанса в IIS 7?

В web.config я устанавливаю таймаут в sessionState на 20 минут. Согласно MSDN, этот тайм-аут определяет количество минут, в течение которых сеанс может простаивать до его отказа. В IIS 7 DefaultWebSite- > Session State- > Cookie Settings- > Time Out автоматически заполняется значением тайм-аута, установленным в web.config, что в моем случае составляет 20 минут. Кроме того, Application Pools- > DefaultAppPool- > Advanced Settings- > idleTimeout, я установил его в 10 минут.

Затем я сделал два теста: Первый тест: я вошел в мое веб-приложение в 15:45, на холостом ходу в течение 10 минут. В 3:55 вечера я попытался использовать свое приложение, меня выгнали. Я думаю, что idleTimeout входит в игру.

Второй тест: я вошел в мое веб-приложение в 16:00, играю с приложением в 16:05, 16:10, 16:15 и 16:20. Я ожидал, что его вышвырнут в 16:20. Но я не был. Я думал, что тайм-аут состояния сеанса (20 минут) в IIS 7 является максимальным временем, в течение которого сеанс пользователя может быть активным до того, как веб-агент вызовет повторную аутентификацию пользователя. По-видимому, из этого теста это не так. Может ли кто-нибудь объяснить это мне? Кроме того, как я могу установить таймаут для вышеуказанного случая?

Ответы

Ответ 1

Тайм-аут сеанса - это скользящий тайм-аут, равный reset для пользователя с заданным значением при каждом посещении сервера.

Тайм-аут простоя приложения запускается, если в течение этого периода не было запросов на ваше приложение.

Таким образом, обычные сценарии:

Time  | User A       | User B       | Session States
------+--------------+--------------+-------------------------------------------
12:00 | Visits Page1 |              | A: New Session, Time-out: 20 minutes
12:02 | Visits Page2 |              | A: Time-out reset: 20 minutes
12:10 |              | Visits Page1 | A: Time-out: 12 min; B: New: 20 minutes
12:15 |              | Visits Page2 | A: Time-out: 07 min; B: Time-out: 20 min
12:22 |              |              | A: times out; B: 13 min remaining
12:32 |              |              | Application Shuts Down (Idle time reached)
12:35 | Visits Page3 |              | A: New Session Starts

Если пользователь A должен был вернуться на сайт после 12:22, у них будет совершенно новый сеанс, и любые значения, которые вы там ранее сохранили, будут потеряны.

Единственный способ гарантировать, что сеанс сохраняется поверх перезапуска приложения, - это настроить службу SessionState или SQL Session States и убедиться, что вы настроили machine.key, чтобы он не автогенерировался каждый раз, когда сервер перезагружается.

Если вы используете стандартные механизмы ASP.NET для аутентификации, тогда ASP.NET выдает два файла cookie каждому пользователю:

  • Идентификатор аутентификации: контролируется параметром Тайм-аут аутентификации, позволяет пользователю автоматически регистрироваться на вашем сайте, если файл cookie не истек, это может быть фиксированным или скользящим, а по умолчанию - 30 минут, что означает, что их токен аутентификации может справиться с более длительным "холостым" периодом, чем их сеанс.
  • Идентификатор сеанса: контролируется настройкой тайм-аута сеанса, позволяет вашему приложению сохранять и получать доступ к значениям для каждого пользователя в течение всего срока их посещения.

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

Отвечая на комментарии:

  • 20-минутный тайм-аут сеанса связан с элементами, которые вы разместили в объекте сеанса пользователей (HttpSessionState) с помощью метода Session.Add(string, object).
  • Это зависит. Если вы правильно настроили machine.key, токены аутентификации все равно будут действительны, и если ваши сеансы больше не являются "InProc", эти также будет сохраняться через перезапуск приложений и будет по-прежнему читабельным - см. примечания выше.