Сброс тайм-аута сеанса в Websphere по событиям Keypress/Mouse

Я установил тайм-аут сеанса в своей WebSphere на 3 минуты (учитывайте, что фактический тайм-аут, который я установил, составляет 30 минут). Я оставил свое приложение открытым и просто навел указатель мыши на приложение J2EE и сделал какое-то нажатие клавиши, которое не отправит никаких страниц. .Даже через 3 минуты сеанс приложения сохраняется. Мне нужно подтвердить, как сеанс сохраняется, когда происходит какое-либо движение мыши/нажатие клавиши? На сервер не отправляется запрос или не было отправлено никаких страниц.

Тайм-аут сеанса для моего приложения поддерживается только на сервере.

Спасибо.


person explorer    schedule 17.01.2014    source источник


Ответы (1)


Похоже, это связано с тем, что WebSphere использует маркер LTPA для аутентификации. В итоге:

  • Когда срок действия веб-сеанса истекает, срок действия учетных данных пользователя не истекает (вы не обязаны повторно входить в систему). Это связано с реализацией маркеров LTPA в WebSphere, и дополнительная информация об этом содержится в документации IBM.
  • По истечении срока действия токена LTPA срок действия учетных данных пользователя истекает (вы вынуждены повторно войти в систему).
  • Время ожидания веб-сеанса зависит от активности пользователя. То есть он сбрасывается на 0 при обнаружении активности пользователя.
  • Время ожидания токена LTPA не связано с активностью пользователя. Время ожидания истекает по истечении времени с даты создания, независимо от того, какая активность пользователя происходит.

С http://www-01.ibm.com/support/docview.wss?uid=swg21078845:

Вопрос 3

Я хочу, чтобы мои пользователи повторно вошли в систему после установленного периода «тайм-аут бездействия». Как должен работать WebSphere Application Server в отношении времени ожидания сеанса и времени ожидания LTPA.

Ответ 3

См. ответ на этот вопрос в пункте 9 следующей статьи developerworks: http://www.ibm.com/developerworks/websphere/techjournal/1003_botzum/1003_botzum.html

Из этой ссылки вы узнаете:

9- Я хочу, чтобы мои пользователи снова входили в систему после установленного периода "тайм-аут бездействия". Как должен работать WebSphere Application Server в отношении времени ожидания сеанса и времени ожидания LTPA?

Срок действия маркера LTPA WebSphere Application Server истекает в зависимости от продолжительности сеанса входа в систему, а не в зависимости от бездействия. Таким образом, сеанс входа в систему WebSphere Application Server не истечет, если пользователь не выполняет никаких действий в течение некоторого периода времени. Однако срок действия HTTPSession истекает из-за бездействия. Если в вашем приложении вам нужно истечь срок использования приложения на основе бездействия, вы должны явно указать это в своем приложении. Вы можете зафиксировать, когда пользователь приходит с истекшим сеансом (на самом деле, с новым сеансом), и заставить его снова войти в систему, если вы считаете, что это необходимо. Имейте в виду, что это подрывает единый вход во всех приложениях.

Второй подход, который представляет собой небольшую вариацию первого, заключается в использовании HTTPSession.getLastAccessTime() для вычисления времени последнего клиентского запроса. Если время слишком далеко в прошлом, вы, конечно, можете отказаться от доступа и принудительно выполнить новую аутентификацию. Любой из этих подходов можно сделать прозрачным для кода приложения с помощью фильтров сервлетов.

Следует отметить, что IBM Tivoli® Access Manager обеспечивает таймауты сеансов аутентификации на основе времени жизни и бездействия.

Пользователи часто спрашивают, почему WebSphere Application Server работает таким образом. Почему не может истечь время простоя сеансов входа в систему? Причина в том, что WebSphere Application Server по своей сути представляет собой слабосвязанную распределенную систему. Серверам приложений, участвующим в домене единого входа, не нужно взаимодействовать друг с другом. Они даже не должны находиться в одной камере. Таким образом, если вы хотите ограничить время простоя токена LTPA (он же токен SSO), вам придется обновлять сам токен, указав время последнего использования при каждом запросе (или, возможно, при первом запросе, полученном в течение одной минуты). ). Это означает, что сам токен будет часто меняться (это означает, что браузер будет часто принимать новые файлы cookie) и что WebSphere Application Server должен будет расшифровывать и проверять входящий токен, когда он будет замечен, чтобы проверить его. Это может быть дорого (сегодня WebSphere Application Server проверяет маркер только при первом использовании на каждом сервере приложений). Эти проблемы можно решить с помощью умного кэширования и тому подобного, но сегодня WebSphere Application Server работает иначе.

person ddbailie    schedule 17.01.2014