Есть веб приложение. Прекрасно работало и работает под tomcat6. Но, после обновления на семерку, такое впечатление, что не работает параметр session-timeout. Такое впечатление, что сессия хранится меньше секунды. Никто не сталкивался?
Уже и <Context useHttpOnly="false"> в context.xml пишу (вроде в семерке там поменяли кое что) — ни хрена не пойму что могло сломаться. Никто не сталкивался?
Здравствуйте, elmal, Вы писали:
E>Есть веб приложение. Прекрасно работало и работает под tomcat6. Но, после обновления на семерку, такое впечатление, что не работает параметр session-timeout. Такое впечатление, что сессия хранится меньше секунды. Никто не сталкивался? E>Уже и <Context useHttpOnly="false"> в context.xml пишу (вроде в семерке там поменяли кое что) — ни хрена не пойму что могло сломаться. Никто не сталкивался?
jsessionid в кукисы попадает вообще?
Здравствуйте, Blazkowicz, Вы писали:
B>jsessionid в кукисы попадает вообще?
Что интересно, похоже попадают. Я логирую ID сессии, и в логах от клиента я четко вижу, что он передается. Более того, вижу, что передается одинаковый ID. Но вот какого то черта сессия живет меньше секунды. Настройки по умолчанию 30 минут, а web.xml приложения вообще 120. Прям такое впечатление, как будто вместо минут там миллисекунды.
Здравствуйте, Blazkowicz, Вы писали:
B>jsessionid в кукисы попадает вообще?
Вообще, у меня проблема даже не с таймаутом. Это лишь предположение. Проблема в том, что отвалилось spring security. То есть из клиента я вызываю логин. Получаю id сессию. Если я без задержек выполню еще какой метод, будет с большой вероятностью все нормально, токен аутентификации будет на месте. Но если я выполню метод через секунду, уже токен аутентификации будет null. Учитывая, что ID сессии с клиента передается неизменное, предполагаю, что сессия просто истекает.
Здравствуйте, elmal, Вы писали:
E>Здравствуйте, Blazkowicz, Вы писали:
B>>jsessionid в кукисы попадает вообще? E>Вообще, у меня проблема даже не с таймаутом. Это лишь предположение. Проблема в том, что отвалилось spring security. То есть из клиента я вызываю логин. Получаю id сессию. Если я без задержек выполню еще какой метод, будет с большой вероятностью все нормально, токен аутентификации будет на месте. Но если я выполню метод через секунду, уже токен аутентификации будет null. Учитывая, что ID сессии с клиента передается неизменное, предполагаю, что сессия просто истекает.
Повесить листенер и подебажить?
Что с протоколами? секьюрная куки не отдается по http
Здравствуйте, PZI, Вы писали:
PZI>Повесить листенер и подебажить?
Листенер на событие истечения сессии? И что дебажить — исходники томката? Не вижу что это мне может дать, если уж цеплять исходники (мне лень ), я и без листенеров найду где там экспайрится все. PZI>Что с протоколами? секьюрная куки не отдается по http
https, soap, blazeds. А секьюрные куки и не надо отдавать на клиент.
Здравствуйте, elmal, Вы писали:
E>Здравствуйте, PZI, Вы писали:
PZI>>Повесить листенер и подебажить? E>Листенер на событие истечения сессии? И что дебажить — исходники томката? Не вижу что это мне может дать, если уж цеплять исходники (мне лень ), я и без листенеров найду где там экспайрится все.
ну если лень, то да. хотя стек помойму посмотреть быстрей, да и при неуверености, что оно вообще экспайрится...
PZI>>Что с протоколами? секьюрная куки не отдается по http E>https, soap, blazeds.
Вопрос о том, переключается ли протокол во время/после логина с секьюрного на несекьюрный. soap и blazeds, как я понимаю, у вас поверх http/hhtps, так что их опускаем.
E>А секьюрные куки и не надо отдавать на клиент.
Здравствуйте, PZI, Вы писали:
PZI>ну если лень, то да. хотя стек помойму посмотреть быстрей, да и при неуверености, что оно вообще экспайрится...
Быстрее всего на 6-й томкат перейти обратно .
PZI>Вопрос о том, переключается ли протокол во время/после логина с секьюрного на несекьюрный. soap и blazeds, как я понимаю, у вас поверх http/hhtps, так что их опускаем.
Нет, не переключается — все идет строго по https сразу.
PZI>Чего?
Возможно не так выразился. Логика такая — как только клиент авторизцется, я ручками формирую объект Authentication в SecurityContextHolder. И далее, как я понял, это все хранится просто в HttpSession.
Depending on the type of application, there may need to be a strategy in place to store the security context between user operations. In a typical web application, a user logs in once and is subsequently identified by their session Id. The server caches the principal information for the duration session. In Spring Security, the responsibility for storing the SecurityContext between requests falls to the SecurityContextPersistenceFilter, which by default stores the context as an HttpSession attribute between HTTP requests. It restores the context to the SecurityContextHolder for each request and, crucially, clears the SecurityContextHolder when the request completes. You shouldn't interact directly with the HttpSession for security purposes. There is simply no justification for doing so — always use the SecurityContextHolder instead.
Соответственно в других методах я периодически проверяю этот объект. Никаких наворотов не использую. Я глубоко не копал, не проверял и не снифил, но вроде на клиент передается только sessionId.
Вообще — проблема похожа на слудующую (описана в FAQ по Spring Security):
3.3.
I have a user who has definitely been authenticated, but when I try to access the SecurityContextHolder during some requests, the Authentication is null. Why can't I see the user information?
If you have excluded the request from the security filter chain using the attribute filters='none' in the <intercept-url> element that matches the URL pattern, then the SecurityContextHolder will not be populated for that request. Check the debug log to see whether the request is passing through the filter chain. (You are reading the debug log, right?).
Но вроде не подходит, никаких фильтров, никаких intercept-url у меня нет, более того — это все прекрасно все работало на 6-м томкате. Я в свое время настолько быстро все это прикрутил и все настолько с первого раза у меня заработало, что не мог нарадываться. И на тебе, маленький апгрейдик, который попробовал сделать только из за одного очень интересного клиента, у которого одного были проблемы с шестым томкатом при запуске как виндовый сервис.
On 24.05.2012 16:25, elmal wrote:
> Вообще, у меня проблема даже не с таймаутом. Это лишь предположение. > Проблема в том, что отвалилось spring security. То есть из клиента я > вызываю логин. Получаю id сессию. Если я без задержек выполню еще какой > метод, будет с большой вероятностью все нормально, токен аутентификации > будет на месте. Но если я выполню метод через секунду, уже токен > аутентификации будет null. Учитывая, что ID сессии с клиента передается > неизменное, предполагаю, что сессия просто истекает.
Поставьте где-нибудь в пределах достижимости сессии breakpoint и гляньте
на неё поподробнее — там есть как минимум getCreationTime и т.п. Заодно
увидите есть ли там ваш объект.
Но я почему-то думаю, что дело не в сессии — вряд ли бы такое прокатило
незамеченным широкой общественностью. В объекте случайно нет
каких-нибудь несереализуемых полей и т.п. ?
Здравствуйте, hrensgory, Вы писали:
H>Поставьте где-нибудь в пределах достижимости сессии breakpoint и гляньте H>на неё поподробнее — там есть как минимум getCreationTime и т.п. Заодно H>увидите есть ли там ваш объект.
Нда ... сессия живее всех живых оказывается. Время создания какое надо, время жизни тоже. Правда ни хрена не пойму что там за ботва. У сессии один аттрибут _flexSession. Который представляет собой объект самого себя. Это как на 6-м томкате, так и на 7-м, 1 в 1, только на 6-м все работает. Могу конечно отказаться от SpringSecurity и пихать в сессию вручную.
H>Но я почему-то думаю, что дело не в сессии — вряд ли бы такое прокатило H>незамеченным широкой общественностью. В объекте случайно нет H>каких-нибудь несереализуемых полей и т.п. ?
Да нет, однозначно все сериализуемо до неприличия.
Здравствуйте, hrensgory, Вы писали:
H>Поставьте где-нибудь в пределах достижимости сессии breakpoint и гляньте H>на неё поподробнее — там есть как минимум getCreationTime и т.п. Заодно H>увидите есть ли там ваш объект.
Нда. Начал дебажить. Контекст и данные аутентификации тупо в ThreadLocalSecurityContextHolderStrategy хранятся в ThreadLocal переменной. SpringSecurity таким образом о потоках ни черта не знает, маппингом сессии на конкретный поток занимается томкат. Пока более подробно не смотрел. Итого — они там в томкате что такое поменяли чтоль?
Здравствуйте, hrensgory, Вы писали:
H>Но я почему-то думаю, что дело не в сессии — вряд ли бы такое прокатило H>незамеченным широкой общественностью. В объекте случайно нет H>каких-нибудь несереализуемых полей и т.п. ?
Нда. Причина, как всегда, оказалась банальной. spring security не был сконфигурен. Соответственно SecurityContextPersistenceFilter не вызывался вообще. Совершенно непонятно, как это могло работать на шестом томкате, что никто этой баги не заметил больше чем за год.
On 25.05.2012 17:44, elmal wrote:
> H>Но я почему-то думаю, что дело не в сессии — вряд ли бы такое прокатило > H>незамеченным широкой общественностью. В объекте случайно нет > H>каких-нибудь несереализуемых полей и т.п. ? > Нда. Причина, как всегда, оказалась банальной. spring security не был > сконфигурен. Соответственно SecurityContextPersistenceFilter не > вызывался вообще. Совершенно непонятно, как это могло работать на шестом > томкате, что никто этой баги не заметил больше чем за год.
Здравствуйте, elmal, Вы писали:
e> H>Но я почему-то думаю, что дело не в сессии — вряд ли бы такое прокатило e> H>незамеченным широкой общественностью. В объекте случайно нет e> H>каких-нибудь несереализуемых полей и т.п. ?
e> Нда. Причина, как всегда, оказалась банальной. spring security не был сконфигурен. Соответственно SecurityContextPersistenceFilter не вызывался вообще. Совершенно непонятно, как это могло работать на шестом томкате, что никто этой баги не заметил больше чем за год.
Может 6й томкат выполнял запросы в одном треде и однажды выставленная tread local variable там жила. А 7й выполняет запросы в разных тредах.
Здравствуйте, ., Вы писали:
.>Может 6й томкат выполнял запросы в одном треде и однажды выставленная tread local variable там жила. А 7й выполняет запросы в разных тредах.
Стоит пул на 50 тредов вроде. И гоняли в свое время под разными пользователями — багов не было обнаружено. Был бы один тред, другой пользователь бы перетирал старого, и периодически бы всплывали баги, когда получаем данные другого пользователя — ни разу такого не было!
Более того, фильтр не был выставлен на весьма неслабо нагруженной онлайн игрушке, и уж там то параллельных тредов однозначно до черта. И как то проблем таких мне неизвестно (под седьмым томкатом я игрушку не пускал, и не собираюсь). Короче, вообще мистика, как оно работало. Одна только теория — томкат 6 так управляет тредами, что одному sessionId строго сопоставляется определенный тред, по другому объяснить не могу.
), я и без листенеров найду где там экспайрится все.
