Блог

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

Проще говоря, я использую компонент CDI User SessionScoped в своем проекте для управления пользовательской информацией и отображения их на страницах jsf. Также j_security_check для решения проблемы аутентификации используется container-managed.

Все в порядке, если сначала выйти из session.invalidate() системы, а затем войти в ту же вкладку браузера с другим пользователем. Но когда я попытался напрямую войти (через login.jsf ) с новым пользователем без предварительного выхода из системы, я обнаружил, что информация о пользователе осталась неизменной.

Я отладил и обнаружил User , что компонент, а также HttpSession экземпляр всегда остаются неизменными, если войти с разными пользователями в том же браузере, пока session.invalidate() не вызывается. Но, как ни странно, идентификатор сеанса был изменен, и я проверил как Java-код, так и Firebug.

 org.apache.catalina.session.StandardSessionFacade@5d7b4092
StandardSession[c69a71d19f369d08b5dddbea2ef0]
attrName = org.jboss.weld.context.conversation.ConversationIdGenerator : attrValue=org.jboss.weld.context.conversation.ConversationIdGenerator@583c9dd8
attrName = org.jboss.weld.context.ConversationContext.conversations : attrValue = {}
attrName = org.jboss.weld.context.http.HttpSessionContext#org.jboss.weld.bean-Discipline-ManagedBean-class com.netease.qa.discipline.profile.User : attrValue = Bean: Managed Bean [class com.netease.qa.discipline.profile.User] with qualifiers [@Any @Default @Named]; Instance: com.netease.qa.discipline.profile.User@c497c7c; CreationalContext: org.jboss.weld.context.CreationalContextImpl@739efd29
attrName = javax.faces.request.charset : attrValue = UTF-8

org.apache.catalina.session.StandardSessionFacade@5d7b4092
StandardSession[c6ab4b0c51ee0a649ef696faef75]
attrName = org.jboss.weld.context.conversation.ConversationIdGenerator : attrValue = org.jboss.weld.context.conversation.ConversationIdGenerator@583c9dd8
attrName = com.sun.faces.renderkit.ServerSideStateHelper.LogicalViewMap : attrValue = {-4968076393130137442={-7694826198761889564=[Ljava.lang.Object;@43ff5d6c}}
attrName = org.jboss.weld.context.ConversationContext.conversations : attrValue = {}
attrName = org.jboss.weld.context.http.HttpSessionContext#org.jboss.weld.bean-Discipline-ManagedBean-class com.netease.qa.discipline.profile.User : attrValue = Bean: Managed Bean [class com.netease.qa.discipline.profile.User] with qualifiers [@Any @Default @Named]; Instance: com.netease.qa.discipline.profile.User@c497c7c; CreationalContext: org.jboss.weld.context.CreationalContextImpl@739efd29
attrName = javax.faces.request.charset : attrValue = UTF-8
  

Приведенный выше блок содержит два последовательных входа в систему и их Session информацию. Мы можем видеть, что экземпляр (1-я строка) тот же, а идентификатор сеанса (2-я строка) отличается. Кажется, что объект сеанса используется повторно, чтобы содержать другой идентификатор сеанса, а платформа CDI управляет жизненным циклом компонента сеанса только в соответствии с объектом сеанса (?).

Мне интересно, может ли быть только один объект сеанса на стороне сервера в том же браузере, если он не признан недействительным?

Поскольку я принимаю j_security_check , мне кажется, что перехватить его и аннулировать старый сеанс не так просто. Итак, возможно ли достичь цели, не изменяя дизайн CDI JSF j_security_check, который можно повторно использовать с другой учетной записью на той же или другой вкладке в том же браузере?

Действительно с нетерпением жду вашего ответа.

Дополнительная информация: Glassfish v3.1 — мой сервер приложений.