Hi Tauren,
I'll answer in-line:
> Thanks, I appreciate your very detailed response. So far, I've not used
> native sessions and have been using http sessions. But I'm intrigued by
> using shiro sessions instead. I'm afraid I may be a little brain dead right
> now, as I'm not quite understanding the issue with native sessions.
> Hopefully you can clear this up.
'native' sessions are Sessions managed entirely by Shiro - no servlet
container or EJB container needed. They allow you to do things like
listening for session events and ultimately, control over how your
sessions are persisted.
Shiro in a web app will default to using the Servlet Container's
HttpSession to support all of the Subject.getSession() calls and
Session interaction. But, if you use the native sessions, Shiro
bypasses the servlet container to manage Session lifecycles and access
itself, but of course fully implements the Servlet specification for
sessions to guarantee that you have the same session experience.
So you would use native sessions if you
1) want the extra features it affords you (SessionListeners,
SessionDAO to query sessions, e.g. "how many users are currently
logged in?)
2) want clients to share a session - for example, if you log in to a
web app and then launch a desktop application, your desktop
application can share session state with your web session.
> 1. So, with native sessions, it sounds like you saying there is no way to
> update my user data (via hibernate) until the user logs out or the native
> session expires. But SessionListener has an onStart(), so why would I not be
> able to?
Because when a session is started, it has no identity data associated
with it. Your onStart implementation will always give you a session
that hasn't yet been associated with a user. After a remember me data
is acquired, we can put it in to the session, but obviously a session
has to be started before we could call setAttribute to do that.
Now we could add a new listener mechanism that is triggered when a
user is associated with a session, but that would be a new feature -
please feel free to add a Jira issue to track this if you'd like it.
> 2. Are there other drawbacks to using native instead of http?
A little more configuration - you'll need to specify a reasonable
SessionDAO implementation to tell Shiro how to persist/acquire your
Session objects. Most people use a nice enterprise caching framework
with disk overflow (important!) such as Ehcache, Coherence, etc.
Shiro has a org.apache.shiro.cache.ehcache.EhCacheManager that you can
use for this purpose. The 'spring' sample application now uses it in
the SecurityManager configuration - you can use that as a starting
point. When using native sessions, you'll also probably want to use a
org.apache.shiro.session.mgt.eis.EnterpriseCacheSessionDAO instance
and inject that into the SessionManager.
There, that's about it. That's the additional configuration that
makes this the only 'drawback' that I can see. I've been using native
sessions in my applications for a long time (years), so you shouldn't
have any problems.
> 3. Are there significant advantages to using native instead of http?
1) SessionListener support
2) Enterprise session clusters - a big deal IMO. Coupled with an
enterprise caching framework (Ehcache+Terracotta), you can have a
beautiful fault-tolerant session cluster with no fear of losing
sessions if a web server crashes. You're also not forced to use
sticky sessions since any machine in the session cluster could service
session requests (sticky sessions is still a good idea for performance
- data locality, etc - but not strictly required).
3) Your sessionDAO implementation can back to a datastore that
supports queries such as a NoSQL engine (simple queries) or
cache+hibernate for complex queries. You'll be able to query for
information like: "Is user X currently logged in?", or "How many
users are currently using the system?" "How many guests vs
authenticated/remembered users do I have". If you correlate sessions
to events or log entries, you can then use that information for very
valuable trend analysis ("What are my users doing during their
sessions? How long do they interact with the application before they
leave it?").
There are a lot of other goodies, but those are the big ones. This is
much easier to do IMO than, say, setting up Tomcat clustering because
you set it up with your configuration mechanism of choice - Spring
XML, INI, whatever.
> For now, I can certainly change my ShiroFilter so it doesn't include my
> static resources. Even if the user record gets updates a couple times when a
> session is created, it will be more acceptable.
> Thanks again for all the assistance, and for the great security framework!
Glad to help! Thanks for being an early adopter and helping us make a
better framework :)
Best,
Les
