Spring Security/JSF/Hibernate Przypadkowe przejęcie kontroli nad Tomcat?

Question

Coś bardzo dziwnego i wstydliwego wydarzyło się we mnie pewnego dnia i nie mam słów, by opisać, co się stało.

Moja aplikacja uruchamia Spring 3 zintegrowana z JSF 2.1, Hibernate 4, Spring Security - wszystko na Tomcat 7. Byłem przez telefon z kimś ważnym z poziomu C i oboje byliśmy jednocześnie w środowisku testowym w tym samym czasie te same strony. Poszedł do strony, do której nawigowałem, w tym samym momencie, gdy na jego stronie pojawiły się moje dane konta osobistego. Nie wierzyłem mu, więc poszedłem do jego biura i na pewno, był jakoś zalogowany jako moje konto, na które nie ma hasła.

Aplikacja będzie zawierała chronione informacje o stanie zdrowia pacjenta, więc kazano mi przedstawić pełny raport z tego, co się wydarzyło, ale nie mogę stwierdzić, jak to było możliwe. Przeszukałem bazę kodu i nic nie znalazłem. Próbowałem odtworzyć dokładnie ten scenariusz przy wielu okazjach i nigdy nie byłem w stanie go odtworzyć. Nie mam nawet wykształconego przypuszczenia, z którego jestem zadowolony.

Myślę, że być może istniała jakaś niebezpieczna operacja wątku na sesjach przechowywanych w implementacji kontekstu aplikacji Tomcat, ale nie jestem w stanie tego udowodnić, jeśli nie jest ona odtwarzalna. Sądziłem też, że skoro Spring Security działa jako filtr przed innymi żądaniami i przekazami, to może interferował jeden z innych filtrów serwletów. Pozostałe dwa to filtr Primefaces File Upload oraz filtr Omnifaces SEO, który niedawno dodałem.

Filtr Omnifaces w rzeczywistości przeszkadzał filtrowi Primefaces File Upload, który musiałem majstrować przy jego konfiguracji, więc dwa z nich grałyby ze sobą dobrze, więc nadal uważam, że to może być również taka możliwość.

Czy są jakieś znane błędy w Spring Security, które spowodowały podobne problemy? Czy są znane problemy z Tomcat dotyczące przypadkowego wyświetlania niewłaściwego stanu sesji z ApplicationContext? Czy ktokolwiek inny napotkał podobny problem lub miał w tym swój wyjątkowy wgląd?

EDIT: Wkrótce po wysłaniu tego znalazłem to, pisał kilka dni temu:

Session mix up - apache httpd with mod_jk, tomcat, spring security - serving data of other user

Jest prawie dokładnie taka sama konfiguracja jak mam Apache httpd + mod_jk wtyczki z przodu Tomcat więc na pewno nie jestem szalony :)

UPDATE:

udało mi się odtworzyć problem wm y środowisko programistyczne bez mod_jk lub Apache z przodu, więc mogę niezawodnie wykluczyć to jako winowajcę.

Answer 1

I zdobione :)

To był rodzaj błędu programistów, ale jest to również śmieszne zachowanie domyślne wiosny. Miałem Fasola zarządzana przez JSF o nazwie SessionBean, którą zadeklarowałem jako @SessionScope. Kiedy integrujesz JSF i Spring, iniekcja zależności JSF koliduje z iniekcją zależną od Spring, więc Spring przepisuje moduł JSF, który obsługuje to, aby po prostu zakryć Spring DI. Więc kiedy deklaruję JSF ManagedBean jako Session Scoped, muszę również nadać mu adnotację @Controller, aby była również rozpoznawana jako Spring Spring.

Okazuje się, że Spring nie rozumie adnotacji JSF @RequestScoped i @SessionScoped.Wiosna ma własną adnotację o nazwie po prostu @Scope(value = "request|session|singleton?|etc...").

Ponieważ Spring nie rozpoznał ustawionego zakresu JSF, traktował nowo utworzony komponent bean jako domyślny dla komponentów bean, jako SINGLETON.

Za każdym razem, gdy ktoś się zalogował, nadpisał właściwość, której użyłem do buforowania zalogowanego użytkownika, który pobrałem od osoby odpowiedzialnej za uwierzytelnianie. Następnie każdy, kto coś zrobił, był zalogowany jako inny użytkownik.

Przyjemna wiosna, przy okazji, aby ostrzec cię,, że źle skonfigurowałeś swoją cholerną fasolkę.

Dzięki za pomoc wszystkim, mam nadzieję, że przyniesie to korzyści przyszłym odwiedzającym!