Hi Bruce, > I've written a quick and dirty ZooKeeper-based cache for handling > distributed session storage for now to avoid adding EHCache or something to > our infrastructure in the next week or two. I can use that with the > EnterpriseCacheSessionDAO and plug that in somewhere so that all sessions > are persisted and retrieved from a ZooKeeper instance.
Sounds good! > But, what's the right way to handle the sessionID stuff? > On the login server, call login on the subject and then get a session? Yep, when you call login by default a session is created. The user identity (the Shiro Subject's PrincipalCollection) is stored in the session by default (this will be configurable in 1.2). The other way to create a session is to just call subject.getSession(); In either case, just call session.getId() and that's your 'handle' to get the session later. > How do I ensure that's validated? Shiro automatically validates the session when it is acquired. For example, if you use the Subject.Builder and provide a session ID, that session ID is wrapped in a SessionKey instance. The SessionKey is submitted to the SessionManager's getSession(sessionKey) method. That method will (eventually, via subclass implementation) validate the acquired session before returning it. > Should I be storing something into the session > to tie it back to that user or is that already handled somewhere in an > appropriate way? This shouldn't be necessary because the PrincipalCollection is stored in the Session already (as a session attribute, and the attribute map is serialized when persisting sessions). > What are best practices for avoiding session hijacking and such? What > support is built into Shiro for helping out with that? It is assumed that non web apps transmit session ids in a secure manner (e.g. SSH or SSL) to prevent MITM attacks. Once in the client application, it is up to the client to ensure it remains safe. For example, in a web app, the session ID cookie is set as an 'HttpOnly' cookie to ensure JavaScript clients can't access it. Other clients will need to perform similar logic themselves, but for most apps, this is usually as simple as keeping it in client-instance-specific runtime memory and never outputting it to disk. HTH, -- Les Hazlewood CTO, Katasoft | http://www.katasoft.com | 888.391.5282 twitter: http://twitter.com/lhazlewood katasoft blog: http://www.katasoft.com/blogs/lhazlewood personal blog: http://leshazlewood.com
