2013-07-09 9 views
5

Używam Apache Shiro w mojej aplikacji internetowej.Shiro resetuje sesję po 2 min.

Przechowuję niektóre parametry w sesji, w szczególności klucz podstawowy obiektu przechowywanego w bazie danych.

Po zalogowaniu użytkownik ładuje obiekt z bazy danych i zapisuje klucz podstawowy w sesji. Następnie w aplikacji użytkownik może edytować dane obiektu i nacisnąć przycisk anulowania lub zapisania.

Oba przyciski uruchamiają usługę RPC, która pobiera zaktualizowane dane na serwer. Obiekt jest następnie aktualizowany w bazie danych przy użyciu klucza podstawowego zapisanego w sesji.

Jeśli użytkownik pozostaje aktywny w aplikacji (wykonując niektóre wywołań RPC), wszystko działa poprawnie. Ale jeśli pozostanie nieaktywny przez 3 minuty, a następnie wykona RPC, wtedy securityUtils.getSubject().getSession() Shiro zwróci wartość null.

Limit czasu sesji wynosi 1 200 000 ms (20 min), więc nie sądzę, że to jest problem.

Kiedy przechodzę przez sesje przechowywane w pamięci podręcznej mojego menedżera sesji, widzę sesję użytkownika org.apache.shiro.session.mgt.SimpleSession,id=6de78f10-b58e-496c-b40a-e2a9a4ad069c, ale kiedy próbuję uzyskać identyfikator sesji z pliku cookie i zadzwonić pod numer SecurityUtils.getSecurityManager().getSession(key), aby uzyskać sesję (gdzie klucz jest Implementacja SessionKey): otrzymuję wyjątek.

Kiedy próbuję budować nowy temat z ID sesji, tracę wszystkie atrybuty zapisane w sesji.

Z przyjemnością zamieszczam kod, aby pomóc w rozwiązaniu problemu, ale spróbowałem tak wielu obejść, że nie wiem od czego zacząć ... Proszę więc dać mi znać, czego potrzebujesz.

Ewentualnie jeśli ktoś wie lepiej udokumentowane niż ramy Shiro Jestem wszystkim uszy (brak Shiro dokumentacji sprawia, że ​​naprawdę zbyt czasochłonne)

Odpowiedz

7

Kwestia ta była związana z config sesji w pliku ini. Jak zwykle w przypadku Shiro, zamówienie miało znaczenie, a niektóre z moich linii były nie na miejscu.

Poniżej jest config, który pracował dla mnie:

sessionDAO = org.apache.shiro.session.mgt.eis.EnterpriseCacheSessionDAO 
#sessionDAO.activeSessionsCacheName = dropship-activeSessionCache 
sessionManager = org.apache.shiro.web.session.mgt.DefaultWebSessionManager 
sessionManager.sessionDAO = $sessionDAO 
# cookie for single sign on 
cookie = org.apache.shiro.web.servlet.SimpleCookie 
cookie.name = www.foo.com.session 
cookie.path =/
sessionManager.sessionIdCookie = $cookie 
# 1,800,000 milliseconds = 30 mins 
sessionManager.globalSessionTimeout = 1800000 
sessionValidationScheduler = 
org.apache.shiro.session.mgt.ExecutorServiceSessionValidationScheduler 
sessionValidationScheduler.interval = 1800000 
sessionManager.sessionValidationScheduler = $sessionValidationScheduler 
securityManager.sessionManager = $sessionManager 
cacheManager = org.apache.shiro.cache.ehcache.EhCacheManager 
securityManager.cacheManager = $cacheManager 
+0

Jaka była poprawka? Nie jest to oczywiste z twojej odpowiedzi, ponieważ nie wyjaśniłeś, co zmieniłeś lub opublikowałeś oryginalną konfigurację. – frhd

4

To brzmi tak, jakby zostały załatwione już problemu. Jak odkryłeś, najważniejszą rzeczą, o której należy pamiętać przy pliku Shiro INI, jest to, że zamówienie ma znaczenie; plik jest analizowany w kolejności, co może być przydatne do konstruowania obiektów używanych w konfiguracji.

Skoro wspomniałeś brak Shiro dokumentacji, chciałem iść do przodu i zwrócić uwagę na dwie tutoriale, że znalazłem pomocne przy uruchamianiu: http://www.javacodegeeks.com/2012/05/apache-shiro-part-1-basics.html i http://www.ibm.com/developerworks/web/library/wa-apacheshiro/.

Istnieje wiele innych postów na blogu, które zapewniają dobre informacje uzupełniające oficjalną dokumentację, jeśli się rozejrzysz.

Powodzenia!