Сохранение и аннулирование Java HttpSession от другого пользователя

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

Что я пытался сделать, так это создать HashMap, используя имя пользователя в качестве ключа и HttpSession в качестве значения (моя фактическая настройка немного сложнее, но после повторяющихся, казалось бы, необъяснимых сбоев, я свел ее к этому простому тесту). Однако всякий раз, когда я пытаюсь сообщить полученному HttpSession о недействительности, он, похоже, делает недействительным текущий сеанс [admin]. Является ли HttpSession неразрывно связанным с текущим запросом?

Или есть совершенно другой способ справиться с этим?

Если это имеет значение, я использую Jetty 6.1.26.


java session jetty invalidation httpsession
person Apropos    schedule 09.12.2012    source источник

Ответы (2)


arrow_upward
1
arrow_downward

Нет прямого пути. Самый простой способ, который я могу придумать, - это сохранить флаг в базе данных (или кэше) и проверять его действительность при каждом запросе.

Или вы можете реализовать прослушиватель сеансов HTTP и сохранить HashMap пользовательских сеансов, к которым можно получить доступ и сделать их недействительными.

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

person Thihara    schedule 10.12.2012
comment
Это почти точно такая же установка, как у меня (сессионный прослушиватель). Проблема заключалась в том, что при вызове session.invalidate() он аннулировал сеанс, из которого я аннулировал, а не целевой сеанс. Мои мысли состоят в том, чтобы установить недопустимый флаг в bean-компоненте с областью действия сеанса и просто использовать аспект для проверки и аннулирования оттуда. Или, я думаю, я мог бы выполнить проверку из bean-компонента с областью запроса. В любом случае, это приводит меня к одному и тому же месту (в зависимости от того, что происходит первым — аспект или конкретизация). - person Apropos; 10.12.2012
comment
Когда вы вызвали аннулирование сеансов других пользователей с этой карты, вы были единственным аннулированным? Возможно, ваша сессия была на карте, и она также была признана недействительной.... - person Thihara; 11.12.2012
comment
Да. Целевой сеанс остался неизменным. - person Apropos; 11.12.2012

arrow_upward
0
arrow_downward

Ну, насколько я могу судить, от этого никуда не деться. Использование bean-компонента с областью запроса не сработало, как я ожидал (хотя это дало мне хорошее представление о том, как работает Spring, перехватывая доступ к полям). В итоге я использовал грязный флаг в моем SessionHandler (компоненте с областью действия сеанса) с очень высокоприоритетной проверкой аспектов и, при необходимости, вызовом invalidate() для сеанса в следующем запросе пользователя. Я все же закончил тем, что все мои SessionHandlers зарегистрировались с помощью SessionManager и метода @PreDestroy, чтобы отменить их регистрацию, чтобы избежать множества нулевых записей на карте.

person Apropos    schedule 21.12.2012