> All I am trying to do is store the Shiro session data in a server-side > secret encrypted cookie. This would be a session cookie no different in > scope or replayability then the JSESSION cookie.
Ahhh - ok, that makes things easier to understand. Thanks for clarifying. I've never tried this before, but there are some things that I can think of: 1. You'll need to be using Shiro's native sessions instead of the servlet container's sessions - servlet containers don't support this AFIK. 2. Create and provide your own SessionDAO implementation to the SessionManager, e.g. in shiro.ini: sessionDAO = com.company.my.CookieSessionDAO securityManager.sessionManager.sessionDAO = $sessionDAO The trick with this is that the SessionDAO has no 'knowledge' of a request/response pair. You'll probably need to acquire the request from a ThreadLocal somewhere so you have access to it and its cookies. I'd recommend subclassing the abstract CachingSessionDAO implementation and implement the remaining methods for retrieving and storing the Session based on cookies, using the thread-bound request/response pair. But I recommend the CachingSessionDAO not because you'll use an enterprise cache - but because every time the SessionManager requests a session, it hits the DAO. This call might occur anywhere from 1 or 2 times up to 30 or 40 times per request - however many times the session is accessed or manipulated during a request. This implies that your CacheManager implementation should be ThreadLocal based - so every read operation acquires the thread-bound Session instance instead of you having to decrypt/deserialize every time read is called or encrypt/serialize every time save/update is called (these calls occur frequently in a single request). Finally, ensure that all ThreadLocals that you bind (request, response, any thread-cached Session) are all cleared from the thread at the end of the request, even if there is an exception. I'd probably do this in a servlet filter that executed _before_ the ShiroFilter, just in case. Does all of this make sense? It is a lot to cover and the approach is a little unorthodox since this use case was never designed for, but it should all still work fine, and without much coding (A thread-clearing ServletFilter, a ThreadLocal-based CacheManager and one SessionDAO subclass). Les
