Problem with sessionDAO and WebFilter

[juminoz <ju...@hotmail.com>]

I'm having an issue enabling session caching when using ShiroFilter.

---
javax.servlet.ServletException:
org.apache.shiro.config.ConfigurationException: Property
'sessionManager.sessionDAO' does not exist for object of type
org.apache.shiro.web.mgt.DefaultWebSecurityManager.
---

After tracing it through, I found the following:
securityManager.sessionManager.sessionDAO = $sessionDAO

sessionManager is from SessionsSecurityManager and sessionDAO is from
DefaultSessionManager (also inherited to DefaultWebSessionManager)

My assumption is that DefaultWebSessionManager is used, but that doesn't
seem to be the case since the property isn't available.

Then I tried adding these 2 lines in the shiro.ini file, but it didn't help.
It actually throws an error as well.

securityManager.sessionManager =
org.apache.shiro.session.mgt.DefaultWebSessionManager

Can you point out what could have gone wrong? I have no problem at all for
non-web.

Thanks,
Jack

--
View this message in context: http://shiro-user.582556.n2.nabble.com/Problem-with-sessionDAO-and-WebFilter-tp6464439p6464439.html
Sent from the Shiro User mailing list archive at Nabble.com.

Re: Problem with sessionDAO and WebFilter

[Les Hazlewood <lh...@apache.org>]

Yeah, because of INI's simplicity, config lines are executed
immediately in the order they are defined; there is no 'definition'
concept where all this stuff is executed in a second pass due to the
complexity that would introduce, especially since
Spring/Guice/JBossXML/etc can do that more effectively than we could.
This is why order matters so much for INI config.

Your comments though aren't the first related to configuring native
sessions and the effects ordering has.  Perhaps it'd be better to get
rid of the 'sessionMode' convenience property entirely to ensure
things are more explicit/known.

Anyway, I'm glad that worked!

Cheers,

Les

On Mon, Jun 13, 2011 at 4:19 PM, juminoz <ju...@hotmail.com> wrote:
> Thanks Les. That solved the problem. I think my problem was with the order of
> initialization when using "native" mode.
>
> Jack
>
> --
> View this message in context: http://shiro-user.582556.n2.nabble.com/Problem-with-sessionDAO-and-WebFilter-tp6464439p6472174.html
> Sent from the Shiro User mailing list archive at Nabble.com.

Re: Problem with sessionDAO and WebFilter

[juminoz <ju...@hotmail.com>]

Thanks Les. That solved the problem. I think my problem was with the order of
initialization when using "native" mode.

Jack

--
View this message in context: http://shiro-user.582556.n2.nabble.com/Problem-with-sessionDAO-and-WebFilter-tp6464439p6472174.html
Sent from the Shiro User mailing list archive at Nabble.com.

Re: Problem with sessionDAO and WebFilter

[Les Hazlewood <lh...@apache.org>]

Hi Jack,

By default, Shiro web apps use the ServletContainerSessionManager
which uses the Servlet Container's session mechanisms using the
standard HttpServletRequest.getSession() API.

If you want to have finer control over the session experience in a web
app, you'll want to enable Shiro's 'native' sessions.

You can do this by explicitly setting 1) the SecurityManager's
'sessionMode' property to 'native' or 2) explicitly configure the
DefaultWebSessionManager instance.

1.
[main]
# no need to call securityManager = DefaultWebSecurityManager - this
is done by default in web environments
securityManager.sessionMode = native

sessionDAO = com.some.SessionDAOImplementation

securityManager.sessionManager.sessionDAO = $sessionDAO

2.
[main]

sessionDAO = com.some.SessionDAOImplementation

sessionManager = org.apache.shiro.web.session.mgt.DefaultWebSessionManager
sessionManager.sessionDAO = $sessionDAO

securityManager.sessionManager = $sessionManager

cacheManager = org.foo.SomeCacheManager

securityManager.cacheManager = $cacheManager


In #1, calling securityManager.sessionMode = native is just a
'shortcut' for instantiating the DefaultWebSessionManager and
injecting it into the securityManager instance.  This can lead to
problems if this is called out of order.

Because of this, I prefer approach #2, which is explicit and defines
the object graph in a well-known, expected order.

Also, notice that the cacheManager is configured last so it can
propagate to all objects that implement the 'CacheManagerAware'
interface.  Ensure your SessionDAO implementation implements this
interface (or alternatively extend the CachingSessionDAO class) to
ensure your DAO can perform caching.

Does this help?

Cheers,

-- 
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

Re: Problem with sessionDAO and WebFilter

[juminoz <ju...@hotmail.com>]

I did a remote debug on the server found the following as well:

securityManager = DefaultWebSecurityManager
securityManager.sessionManager = DefaultWebSessionManager
securityManager.sessionManager.sessionDAO = MemorySessionDAO

This means that sessionDAO exists and it should work.

Thanks,
Jack

--
View this message in context: http://shiro-user.582556.n2.nabble.com/Problem-with-sessionDAO-and-WebFilter-tp6464439p6464449.html
Sent from the Shiro User mailing list archive at Nabble.com.