Hi Les, Yes, this approach makes a lot of sense. It is actually similar to what we have. I made a few modifications to our codebase so that the Shiro filter can be first in line. First, I got this to work without using shiro native sessions. Then I enabled native sessions by adding some lines to shiro.ini. The first part of my shiro.ini [main] section looks like:
hazelcastCacheManager = com.security.hazelcast.HazelcastCacheManager sessionDAO = org.apache.shiro.session.mgt.eis.EnterpriseCacheSessionDAO sessionManager = org.apache.shiro.web.session.mgt.DefaultWebSessionManager securityManager.sessionManager = $sessionManager securityManager.sessionManager.sessionDAO = $sessionDAO sessionIdGenerator = com.security.SimpleSessionIdGenerator securityManager.sessionManager.sessionDAO.sessionIdGenerator = $sessionIdGenerator securityManager.cacheManager = $hazelcastCacheManager When I run it, I still notice that it will create first tomcat sessionIds, and then shiro ids. Here is a stack trace when I break on HttpServletRequestWrapper.getSession() http://shiro-user.582556.n2.nabble.com/file/n6821089/StackAtGetSessionInOurFilter.png It shows that a tomcat sessionId is created. For a bit more details, on the same page request, here's another stack trace: http://shiro-user.582556.n2.nabble.com/file/n6821089/2ndStackLaterOnInSamePageRequest.png It shows the request coming in correctly and handled by shiro. On the first stack trace, my expectation is that the getSession() request in our app's filter, FxFilter, would cause shiro's sessionId to be generated. Much thanks, Dan -- View this message in context: http://shiro-user.582556.n2.nabble.com/Using-native-web-sessions-tp6799265p6821089.html Sent from the Shiro User mailing list archive at Nabble.com.
