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

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

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

Благодарю.

1 ответ

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

  • По истечении срока действия веб-сессии учетные данные пользователей не истек (вы не должны повторно войти в систему). Это связано с внедрением тестеров 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?

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

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

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

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

licensed under cc by-sa 3.0 with attribution.