2013-09-19 5 views
0

Я работаю над устаревшим приложением (Spring 2.2.5, Spring Security 2.0.8). Аутентификация осуществляется с помощью пользовательского PreAuthenticationProcessingFilter, где SecurityContext заполняется объектом Authentication. Эта аутентификация доступна в большинстве мест (будь то прямой вызов SecurityContextHolder или аргументы AccessDecisionManager/AfterInvocationProvider). Однако есть места, где объект аутентификации (доступ к которому SecurityContextHolder) имеет значение NULL. То, что действительно является bizzare, заключается в том, что это происходит в рамках одного запроса Http. Класс A получает объект аутентификации, класс B, вызываемый позже в стек, получает значение null. Естественно, это происходит в том же потоке, который исключает самый простой ответ на эту проблему. Похоже, что несмотря на то, что поток является тем же самым, SecurityContextHolder возвращает разные объекты SecurityContext (SecurityContext.toString() возвращает разные адреса памяти). Важно то, что место, где это происходит, - это не ваш обычный весенний боб. Это довольно настраиваемая подсистема модуля с пользовательским загрузчиком классов, и я думаю, что это может что-то сделать с этим эффектом bizzare.Spring SecurityContext получает «lost»

Вопрос: Что, помимо нереста другой нити, может привести к тому, что SecurityContextHolder «потеряет» объект SecurityContext?

ответ

0

Ключевой проблемой здесь был SecurityContextHolder с использованием ThreadLocal и моей подсистемы с использованием пользовательского загрузчика классов. SecurityContextHolder, вызываемый внутри класса, созданный пользовательским загрузчиком классов, заставит загрузчик классов загружать класс SecurityContextHolder и инициализировать его пустым контекстом, следовательно, описанный выше эффект.

Короче говоря, ThreadLocal и пользовательские загрузчики классов не смешиваются хорошо, как описано здесь:

Effect of ThreadLocals and side-by-side classloading

Смежные вопросы