shiro-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jared Bunting <jared.bunt...@digitalreasoning.com>
Subject DefaultWebSecurityManager and native vs http sessions
Date Tue, 19 Jul 2011 12:52:27 GMT
So, I've run into a bit of a pickle with DefaultWebSecurityManager and
native vs http sessions.

The DefaultWebSecurityManager exposes two methods, ostensibly for the
purposes of determining how sessions are managed:

setSessionManager(SessionManager)

and

setSessionMode(String)

However, it would appear that if I call:

setSessionManager(new MyCustomSessionManager())

and then

setSessionMode("native")

the SessionManager is overridden. 

This is a bit of a gotcha, but can be easily avoided by not calling
setSessionMode.  (calling them in the reverse order seems contrary to
the nature of setters)  The problem with not calling setSessionMode is
that it appears to actually matter - if I leave it to it's default
(http), but set a DefaultWebSessionManager, then things break horribly
(apparently due to the use of isHttpSessionMode by AbstractShiroFilter
for redirect rewriting).  Sessions get forgotten, etc.  This also seems
contrary to the nature of setters. 

So, my suggestion is this:

introduce a new interface,

public interface WebSessionManager extends SessionManager {
  boolean isHttpSession();
}

and replace the implementation of isHttpSessionMode in
DefaultWebSessionManager with this:

  public boolean isHttpSessionMode() {
    if(this.sessionManager instanceof WebSessionManager) {
      return ((WebSessionManager)sessionManager).isHttpSession();
    } else {
      return true;
    }
  }


Another option would be to work out a way to delegate the url rewriting
of the session id to the session manager that doesn't require if
statements at the filter level.

Thoughts?  If there's merit the idea, I'd be happy to code up a patch
for it.

Thanks,
Jared

Mime
View raw message