0

ServletContainerSessionManager isn't a ValidatingSessionManager; does it defer to the underlying container to handle orphan cleanup? That doesn't seem right.

I assume that switching to DefaultWebSessionManager, as it's a full-featured implementation, would have no risks or drawbacks? Is there any reason that's not the default for this module?

MaVRoSCy
  • 17,747
  • 15
  • 82
  • 125
coyotesqrl
  • 142
  • 2
  • 5

1 Answers1

1

ServletContainerSessionManager does indeed defer to the container for all session related functionality. ShiroWebModule defaults to this simply because that was the default already expected in the DefaultWebSecurityManager - the intention was to keep the defaults the same whether you were using the basic ini setup, spring, or guice.

That being said, if your need is for managing the sessions within Shiro, there is no reason to not switch to DefaultWebSessionManager. Indeed, that is why the bindSessionManager method exists.

To switch, simply override bindSessionManager:

@Override
protected void bindSessionManager(AnnotatedBindingBuilder<SessionManager> bind) {
    bind.to(DefaultWebSessionManager.class).asEagerSingleton();
}
jbunting
  • 886
  • 5
  • 10
  • Thanks for confirming my suspicions. I'd already made the switch and saw no regressions, but just wanted to be sure. – coyotesqrl Oct 12 '12 at 23:55