Я искал решение этой проблемы довольно много времени и безрезультатно, поэтому я задаю вопрос здесь.
Проще говоря, я использую компонент SessionScoped Bean User вМой проект для управления пользовательской информацией и отображения ее на страницах JSF.Также управляемый контейнером j_security_check используется для решения проблемы аутентификации.
Все хорошо, если сначала выйти из системы с помощью session.invalidate(), а затем войти в ту же вкладку браузера с другим пользователем.Но когда я попытался напрямую войти (через login.jsf) с новым пользователем без выхода из системы, я обнаружил, что информация о пользователе осталась неизменной.
Я отладил и обнаружил bean-компонент 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 - мой appserver.