объект нулевой в карте атрибутов сеанса при доступе из фильтра сервлета - PullRequest
1 голос
/ 22 марта 2012

У меня есть фильтр сервлетов для принудительной аутентификации пользователей.Он проверяет наличие ненулевого объекта в HttpSession.По какой-то причине, которую я не могу понять, сессия содержит объект с правильным именем, но HttpSession.getAttribute возвращается как ноль.Вот процесс, через который он проходит.

со страницы входа в систему вызывается действие, содержащее следующий код подтверждения пользователя.На данный момент я на 100% уверен, что объект «логин» не является нулевым.

if (passWordIsValid) {
   HttpSession session = getCurrentFacesSession();
   session.setAttribute("loginBean", login);
return "welcome";
} else {
   // error handling here 
}

Результат «Добро пожаловать» переходит на страницу лицевой страницы со следующим кодом:

<h:outputText value="Welcome #{sessionScope.loginBean.email}"/>

Этот код успешно показывает адрес электронной почты, подтверждая, таким образом, что в области видимости сеанса есть объект loginBean, и он не равен NULL.Командная ссылка на этой странице приветствия отправляет запрос в другое представление.Когда фильтр сервлетов перехватывает запрос, он делает следующее:

HttpSession session = ((HttpServletRequest) servletRequest).getSession();
Object beanObj = session.getAttribute("loginBean");
if (beanObj!=null) {
   chain.doFilter(servletRequest,servletResponse);
} else {
   // code to send back to login page
}

ВСЕГДА отправляет пользователя обратно на страницу входа в систему, потому что beanObj всегда возвращает ноль.Это загадка, которую я не могу разгадать.Какие-либо предложения?

РЕДАКТИРОВАНИЕ Для дальнейшей отладки я добавил код регистрации в фильтр сервлета для вывода атрибутов в сеансе:

for (Enumeration<String> e = session.getAttributeNames(); e.hasMoreElements();) {
    log("Found Session attribute="+e.nextElement());
}

Вывод подтверждает, что существует атрибут с именем"loginBean" в сессии!Это сводит с ума ...

EDITED

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

HttpSession session = ((HttpServletRequest) servletRequest).getSession();
String s = "loginBean";
Object beanObj = session.getAttribute(s);
if (beanObj!=null) {
   chain.doFilter(servletRequest,servletResponse);
} else {
   // code to send back to login page
}

То же поведение ...

отладка

Я зарегистрировал HttpSessionAttributeListener.Вывод подтверждает, что компонент был добавлен в сеанс.Последующие экземпляры этого компонента не будут заменены или удалены из сеанса.Я не уверен, что делать с использованием отладчика, особенно для чего-то такого сложного (целый веб-контейнер, работающий в JVM.)

1 Ответ

0 голосов
/ 22 марта 2012

Хорошо, теперь я чувствую себя глупо.Это была ошибка в коде фильтра сервлетов;два на самом деле.Во-первых, мне не хватало оператора return после одного из вызовов метода doFilter (request, response).Во-вторых, JSESSIONID добавлялся к URL-адресу, и я не учел это в коде, который всегда разрешает страницу входа.Ну, на самом деле я пытался объяснить это, но я сделал это неправильно.Я написал это так, как если бы JSESSIONID был параметром запроса, например так: JSESSIONID = blah, когда на самом деле это не параметр запроса, он использует точку с запятой, например:; JSESSIONID = blah.

Сочетание этих ошибок создавало впечатление, что фильтр сервлета не смог найти объект в сеансе;но на самом деле происходило то, что сообщение журнала было получено из ПРЕДЫДУЩЕГО запроса - оно никогда не доходило до проверки сеанса на последующих запросах, когда бин действительно был там.Упс!Для тех, у кого эта проблема возникнет в будущем, я расскажу вам, как я это выяснил: я удалил весь код из фильтра сервлета, который выполнял переадресацию или перенаправление, и поместил один doFilter () внизу, а затем поместил операторы регистрациичтобы увидеть ценность.Тогда было сразу видно, что происходит.HttpSessionAttributeListener также был полезен.

...