Spring Security/JSF/Hibernate Случайное угонение сеанса на Tomcat?

Question

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

Мое приложение работает под управлением Spring 3, интегрированного с JSF 2.1, Hibernate 4, Spring Security и Tomcat 7. Я разговаривал по телефону с кем-то важным из C-level, и мы оба одновременно работали в тестовой среде на тех же страницах. Он пошел, чтобы перейти на страницу, к которой я переходил, в тот же момент, когда на его странице появились данные моей личной учетной записи. Я не поверил ему, поэтому я подошел к его офису и, конечно же, он как-то вошел в мою учетную запись, для которой у него нет пароля.

Приложение будет защищать информацию о состоянии здоровья пациента, поэтому мне было приказано предоставить полный уровень отчета о том, что произошло, но я не могу найти, как это было возможно. Я искал кодовую базу и ничего не придумал. Я несколько раз пытался воспроизвести точный сценарий и так и не смог его воспроизвести. У меня даже нет образованного предположения, что я счастлив.

Я думаю, что, возможно, в сеансах, хранимых в реализации контекста приложения Tomcat, могла быть какая-то небезопасная операция с потоками, но у меня нет способа доказать это, если она не воспроизводима. Я также подумал, что поскольку Spring Security работает как фильтр, опережая другие запросы и перенаправляя, возможно, вмешивался один из других фильтров сервлетов. Двумя другими были фильтр загрузки файлов Primefaces и фильтр Omnifaces SEO, который я недавно добавил.

Фильтр Omnifaces на самом деле мешал фильтру загрузки файлов Primefaces, который мне пришлось повозиться с его конфигурацией, чтобы они оба хорошо играли друг с другом, поэтому я все еще чувствую, что это тоже возможно.

Есть ли какие-либо известные ошибки в Spring Security, которые вызвали подобные проблемы? Есть ли известные проблемы с Tomcat, связанные с случайным обслуживанием неправильного состояния сеанса из ApplicationContext? Кто-нибудь еще сталкивался с подобной проблемой или имел какое-то уникальное понимание этого?

РЕДАКТИРОВАТЬ: Вскоре после публикации этого я нашел это, опубликовано только несколько дней назад:

Смешивание сессии - apache httpd с mod_jk, tomcat, spring security - обслуживание данных другого пользователя

Это почти такая же настройка, как и у меня плагин Apache httpd+mod_jk перед Tomcat, так что я точно не сумасшедший:)

ОБНОВИТЬ:

Мне удалось воспроизвести проблему в моей среде разработки без mod_jk или Apache, поэтому я могу с уверенностью исключить это как виновника.

Answer 1

Я понял:)

Это было своего рода ошибкой разработчика, но это также смешное поведение Spring по умолчанию. У меня был управляемый компонент JSF под названием SessionBean, который я объявил @SessionScope, Когда вы интегрируете JSF и Spring, внедрение зависимостей JSF вступает в конфликт с внедрением зависимостей Spring, поэтому Spring переписал модуль JSF, который обрабатывает это, чтобы вместо этого просто обернуть Spring DI. Поэтому, когда я объявляю JSF Managed Bean как Session Scoped, я также должен дать ему @Controller аннотации, чтобы он также распознавался как Spring Bean.

Оказывается, что Spring, однако, не понимает JSF @RequestScoped а также @SessionScoped аннотаций. Spring имеет свою собственную аннотацию под названием просто @Scope(value = "request|session|singleton?|etc..."),

Поскольку Spring не распознал установленную мною область JSF, он рассматривал вновь созданный bean-компонент по умолчанию для bean-компонентов как SINGLETON.

Поэтому каждый раз, когда кто-то входил в систему, он перезаписывал свойство, которое я использовал для кэширования вошедшего в систему пользователя, который я выбрал из принципала аутентификации. Тогда каждый, кто что-то делал, был зарегистрирован как другой пользователь.

Между прочим, здорово, что я предупредил тебя, что ты неправильно настроил свой чертов боб.

Спасибо всем за помощь, надеюсь, это пойдет на пользу будущим посетителям!