Thanks Les, this is exactly what I was looking for. On Aug 24, 2010, at 10:48 AM, Les Hazlewood-2 [via Shiro User] wrote:
> > 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 > > > View message @ > http://shiro-user.582556.n2.nabble.com/Permission-checking-on-client-side-tp5450587p5457995.html > > To unsubscribe from Permission checking on client side ?, click here. > -- View this message in context: http://shiro-user.582556.n2.nabble.com/Permission-checking-on-client-side-tp5450587p5458141.html Sent from the Shiro User mailing list archive at Nabble.com.
