request.getUserPrincipal() по-прежнему не является нулевым после того, как сеанс недействителен

Question

У меня есть веб-приложение, развернутое на сервере приложений websphere 7.0. Вход пользователя с использованием/j_security_check. Когда таймаут сеанса имеет сеанс ivnvalidates, но request.getUserPrincipal() по-прежнему не равен нулю. Я ожидаю, что он должен быть нулевым. Как очистить пользователя?

Answer 1

Я нашел решение в сфере документации.

1. В административной консоли выберите Безопасность> Глобальная безопасность.
2. В разделе «Пользовательские свойства» нажмите «Создать».
3. В поле «Имя» введите com.ibm.ws.security.web.logoutOnHTTPSessionExpire.
4. В поле «Значения» введите true.
5. Нажмите «Применить» и «Сохранить», чтобы сохранить изменения в вашей конфигурации.
6. Повторно синхронизировать и перезагружать сервер.

Answer 2

Главное, чтобы иметь в виду, является действительным/недействительным HTTPSession не то же самое, как безопасность.

Они совершенно разные.

Как только вы авторизованы сервером, вы все равно можете работать с приложениями без HTTPSession, если хотите.

Как только вы аутентифицированы сервером, вы получаете токен LTPA, который возвращается в ваш браузер, и токен LTPA активен, например, за 2 часа (по умолчанию).

Если истекает срок действия вашего HTTP-сеанса, который не влияет на токен LTPA, если вы ничего не делаете.

Вы можете попробовать: ibm_security_logout, что приведет к недействительности токена LTPA.

Я предполагаю, что с более поздними версиями API Servlet у нас есть соответствующая операция выхода из системы, которая устраняет необходимость в этом.

НТН

Manglu

Answer 3

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

Если вы используете SSO (один знак) между различными приложениями, может быть немного недостаток использования параметра com.ibm.ws.security.web.logoutOnHTTPSessionExpire = true. Этот параметр по существу делает недействительным токен LTPA. Поскольку кэш безопасности на сервере обновляется с токена LTPA, когда он истекает время, недействительный LTPA вызовет повторную проверку (вход в систему) пользователя для остальных приложений [1].

Ответ на вопрос 9 (который, похоже, совпадает с нашим вопросом) в [2] содержит идеи для двух альтернативных обходных путей для этой проблемы, где вы можете отключить проверку подлинности с использованием сервлет-фильтров на основе времени жизни и бездействия.

[1]: Security Cache, LTPA Token, and Session Time Outs (требуется Логин)

[2]: Q & A: Frequently asked questions about WebSphere Application Server security