You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@shiro.apache.org by drmike01 <ms...@gmail.com> on 2012/06/07 23:13:36 UTC
Native session management for web sessions
I'm struggling a bit with using native session management in my web
application, which doesn't seem to be persisting sessions for as long as I
have configured them.
My shiro.ini is configured with the following relevant lines, and to me this
seems (based on documentation and forum messages) to be correct. I have a
very long timeout (72 hrs) because the app is used in an already-secure
environment, so this is the maximum time required by our regulations
(basically a CYA thing), and I need to be able to cache the sessions because
of the length of time.
sessionManager = org.apache.shiro.web.session.mgt.DefaultWebSessionManager
securityManager.sessionManager = $sessionManager
securityManager.sessionManager.globalSessionTimeout = 259200000
I also tried adding in securityManager.sessionMode = native, which I saw in
one comment, but that is apparently deprecated as of 1.2. It made some
comments in the logs when it started, and seemed okay with that, but I don't
think it helped.
The problem is that, when I use my application (a web-based mobile app
wrapped in PhoneGap), the sessions only seem to persist less than 30
minutes, I haven't really been able to figure out exactly how long, and
nowhere close to the 72 hrs I have configured. The (hopefully relevant) log
output looks like this when I start the app:
2012-06-07 13:33:42,841 [pool-3-thread-1] DEBUG
org.apache.shiro.config.ReflectionBuilder .resolveReference:235 -
Encountered object reference '$sessionManager'. Looking up object with id
'sessionManager'
2012-06-07 13:33:42,845 [pool-3-thread-1] DEBUG
org.apache.commons.beanutils.ConvertUtils .convert:460 - Convert string
'259200000' to class 'long'
2012-06-07 13:33:42,845 [pool-3-thread-1] DEBUG
org.apache.commons.beanutils.converters.LongConverter .convert:127 -
Converting 'String' value '259200000' to type 'Long'
2012-06-07 13:33:42,845 [pool-3-thread-1] DEBUG
org.apache.commons.beanutils.converters.LongConverter .convertToType:266 -
No NumberFormat, using default conversion
2012-06-07 13:33:42,845 [pool-3-thread-1] DEBUG
org.apache.commons.beanutils.converters.LongConverter .convert:158 -
Converted to Long value '259200000'
2012-06-07 13:33:42,846 [pool-3-thread-1] DEBUG
org.apache.shiro.realm.AuthorizingRealm .getAuthorizationCacheLazy:234 - No
authorizationCache instance set. Checking for a cacheManager...
2012-06-07 13:33:42,846 [pool-3-thread-1] INFO
org.apache.shiro.realm.AuthorizingRealm .getAuthorizationCacheLazy:248 - No
cache or cacheManager properties have been set. Authorization cache cannot
be obtained.
And when I try to access the app after the timeout has occurred:
2012-06-07 11:12:50,181 [http-bio-8080-exec-2] DEBUG
org.apache.shiro.session.mgt.DefaultSessionManager .retrieveSession:218 -
Unable to resolve session ID from SessionKey
[org.apache.shiro.web.session.mgt.WebSessionKey@59bd523d]. Returning null
to indicate a session could not be found.
2012-06-07 11:12:50,182 [http-bio-8080-exec-2] DEBUG
org.apache.shiro.web.servlet.SimpleCookie .readValue:366 - Found
'rememberMe' cookie value
[ex//hFAQh3oCzHKpoRYmo93Wb2ufljgur+iSqXWvIGQIE5N8P8iqdetF+wIYWW+YOwd5Db+UkDjl4YIOv+8HOY6BQb1tf3hfTYoR7GMP+1m7/4ef3d1mf2SWxIbQeOxS1EAOb0q6GlQMaqg+Aj3G4FtBPSdiTMgk+74eeB3ogAHWDoniKKyuauuduGs/8bBOBrP30HaGutKOhgK21HNlndFmdwDtcbFHVQE8wrBfhpJH/g0aSu4eCPVkeMwKzfJtF+a2Fv6vQx15jMWJt6i6jd7HPTWTUaKoUjg7mnCtx13f9BqRa0+Feh+YZVIRNyXuHpO4lDCEXQdVSYsN3HfXg+hAA/HQHxc06HhScIDxeD0LfO6PsOBIFebWTflwmxBiFBI+z3IRLEXnnFOU45MBrVbrCE1a84G3YGwCCeoUf9rAX4OMiTWMV50izqQZOo/e88QxQxhhfNyhtbpBOLbtOBoZErgEpQSO94VvRCZ6xpLyE+v8NX4fzASY9Q4ZCmalTE0r6XwOiN1bsUGwfzuURQ]
2012-06-07 11:12:50,182 [http-bio-8080-exec-2] DEBUG
org.apache.shiro.mgt.DefaultSecurityManager .resolvePrincipals:495 - Found
remembered PrincipalCollection. Adding to the context to be used for
subject construction by the SubjectFactory.
2012-06-07 11:12:50,182 [http-bio-8080-exec-2] DEBUG
org.apache.shiro.session.mgt.DefaultSessionManager .create:175 - Creating
new EIS record for new session instance
[org.apache.shiro.session.mgt.SimpleSession,id=null]
Based on these logs, what it seems to me is that it isn't caching at all,
even in memory, and therefore can't find sessions when whatever session it
is looking at expires. It is, however, storing cookies, so that's happening
okay. It acts like it's using the servlet containers sessions, but I don't
see how it could with that configuration. I've also seen a bunch of logs
that suggest it does session clean-ups, but it never seems to find any; that
may not be related.
Thank you in advance for any insight on this one. I'm kind of stumped.
--
View this message in context: http://shiro-user.582556.n2.nabble.com/Native-session-management-for-web-sessions-tp7577474.html
Sent from the Shiro User mailing list archive at Nabble.com.
Re: Native session management for web sessions
Posted by Jared Bunting <ja...@peachjean.com>.
Glad you got it worked out. That configuration certainly looks simpler.
On Jun 8, 2012 11:22 AM, "drmike01" <ms...@gmail.com> wrote:
> Thank you guys very much! This turned out to be the right line to pursue,
> although with some changes that I'll detail below in case anybody else has
> the same question in the future.
>
> The maxAge on the Cookie that Shiro sets is -1, which means it expires when
> the browser closes. For a mobile web app wrapped in PhoneGap, it
> essentially
> never closes unless the OS closes it out as part of its regular
> app-cleaning
> processes, or the user force closes, in which case the cookie is wiped and
> you get the error messages that Les pointed out when the user tries to
> reconnect.
>
> As Jared described, to prevent that you need to change the default age of
> that cookie. The method that Jared pointed out caused some odd issues
> (like
> it expected me to name the cookie, and it seems that by setting the cookie
> myself I was taking on a lot of config responsibility), so I resolved it
> all
> by changing it to one line of config code:
>
> securityManager.sessionManager.sessionIdCookie.maxAge = 288000
>
> That was it. Now the sessions last the full 72 hours, because that wasn't
> broken to begin with, and they won't cancel out if the app gets killed for
> whatever reason. Note too that the cookie's age is set in seconds, while
> the session's age is set in milliseconds.
>
> Thanks again!
>
> --
> View this message in context:
> http://shiro-user.582556.n2.nabble.com/Native-session-management-for-web-sessions-tp7577474p7577483.html
> Sent from the Shiro User mailing list archive at Nabble.com.
>
Re: Native session management for web sessions
Posted by drmike01 <ms...@gmail.com>.
Thank you guys very much! This turned out to be the right line to pursue,
although with some changes that I'll detail below in case anybody else has
the same question in the future.
The maxAge on the Cookie that Shiro sets is -1, which means it expires when
the browser closes. For a mobile web app wrapped in PhoneGap, it essentially
never closes unless the OS closes it out as part of its regular app-cleaning
processes, or the user force closes, in which case the cookie is wiped and
you get the error messages that Les pointed out when the user tries to
reconnect.
As Jared described, to prevent that you need to change the default age of
that cookie. The method that Jared pointed out caused some odd issues (like
it expected me to name the cookie, and it seems that by setting the cookie
myself I was taking on a lot of config responsibility), so I resolved it all
by changing it to one line of config code:
securityManager.sessionManager.sessionIdCookie.maxAge = 288000
That was it. Now the sessions last the full 72 hours, because that wasn't
broken to begin with, and they won't cancel out if the app gets killed for
whatever reason. Note too that the cookie's age is set in seconds, while
the session's age is set in milliseconds.
Thanks again!
--
View this message in context: http://shiro-user.582556.n2.nabble.com/Native-session-management-for-web-sessions-tp7577474p7577483.html
Sent from the Shiro User mailing list archive at Nabble.com.
Re: Native session management for web sessions
Posted by Jared Bunting <ja...@peachjean.com>.
I would say that I would wholly expect force closing the app to wipe
out the cookie, the way that shiro is configured by default. If you
want a force-close to not wipe out the cookie, I think my last message
will help you out.
-Jared
On Thu 07 Jun 2012 09:03:08 PM CDT, drmike01 wrote:
> Interesting, so I tested it again after three hours, and it worked fine,
> picked up the correct cookie and went on as if nothing had happened. I'm
> not sure what is different from what I had previously configured, but it's
> possible that something else caused the scenario I'm seeing, like I had to
> force close the app at one point (maybe that wipes out cookies). I'll try
> again tomorrow and see if it's still working, and if so, close up this
> question.
>
> Thanks for the help guys, it may have magically fixed itself, but if it
> magically reappears again I'll know what the culprit is!
>
> --
> View this message in context: http://shiro-user.582556.n2.nabble.com/Native-session-management-for-web-sessions-tp7577474p7577479.html
> Sent from the Shiro User mailing list archive at Nabble.com.
Re: Native session management for web sessions
Posted by drmike01 <ms...@gmail.com>.
Interesting, so I tested it again after three hours, and it worked fine,
picked up the correct cookie and went on as if nothing had happened. I'm
not sure what is different from what I had previously configured, but it's
possible that something else caused the scenario I'm seeing, like I had to
force close the app at one point (maybe that wipes out cookies). I'll try
again tomorrow and see if it's still working, and if so, close up this
question.
Thanks for the help guys, it may have magically fixed itself, but if it
magically reappears again I'll know what the culprit is!
--
View this message in context: http://shiro-user.582556.n2.nabble.com/Native-session-management-for-web-sessions-tp7577474p7577479.html
Sent from the Shiro User mailing list archive at Nabble.com.
Re: Native session management for web sessions
Posted by Jared Bunting <ja...@peachjean.com>.
One thought is that the session cookie, by default, is not set to
persist beyond the browser closing. Not sure if that's what you're
seeing, or if it would be an issue in PhoneGap, but it might be a bit
of a gotcha.
I believe you can fix that with something like this:
cookie=org.apache.shiro.web.servlet.SimpleCookie
cookie.maxAge=288000 # i bumped this up to 80 hrs, just to be
safe...the session will still expire at 72
sessionManager.cookie=$cookie
Or I could be way off base.
-Jared
On Thu 07 Jun 2012 05:35:32 PM CDT, drmike01 wrote:
> I just did an initial login and subsequent access, and it appears to be
> finding that cookie. I'll have to try again in a little bit to see if,
> after a period of time, I get a different response. The logs had the below:
>
> 2012-06-07 15:24:21,819 [http-bio-8080-exec-3] DEBUG
> org.apache.shiro.session.mgt.DefaultSessionManager .create:175 - Creating
> new EIS record for new session instance
> [org.apache.shiro.session.mgt.SimpleSession,id=null]
> 2012-06-07 15:24:21,820 [http-bio-8080-exec-3] DEBUG
> org.apache.shiro.web.servlet.SimpleCookie .addCookieHeader:226 - Added
> HttpServletResponse Cookie [JSESSIONID=6ca59e24-d8c8-497c-bcc4-3b2d02a9d121;
> Path=/mhrx; HttpOnly]
> ... some of my own debugging
> 2012-06-07 15:25:29,167 [http-bio-8080-exec-5] DEBUG
> org.apache.shiro.web.servlet.SimpleCookie .readValue:366 - Found
> 'JSESSIONID' cookie value [6ca59e24-d8c8-497c-bcc4-3b2d02a9d121]
>
> I'm not sure it matters, but I do have my own Realm implementation, as well
> as my own LoginFilter that extends AuthenticatingFilter. I don't recall
> seeing anything in the superclasses that could screw this part up, though.
>
> I'll post back in a little bit with what happens with the expired attempt.
>
> --
> View this message in context: http://shiro-user.582556.n2.nabble.com/Native-session-management-for-web-sessions-tp7577474p7577476.html
> Sent from the Shiro User mailing list archive at Nabble.com.
Re: Native session management for web sessions
Posted by drmike01 <ms...@gmail.com>.
I just did an initial login and subsequent access, and it appears to be
finding that cookie. I'll have to try again in a little bit to see if,
after a period of time, I get a different response. The logs had the below:
2012-06-07 15:24:21,819 [http-bio-8080-exec-3] DEBUG
org.apache.shiro.session.mgt.DefaultSessionManager .create:175 - Creating
new EIS record for new session instance
[org.apache.shiro.session.mgt.SimpleSession,id=null]
2012-06-07 15:24:21,820 [http-bio-8080-exec-3] DEBUG
org.apache.shiro.web.servlet.SimpleCookie .addCookieHeader:226 - Added
HttpServletResponse Cookie [JSESSIONID=6ca59e24-d8c8-497c-bcc4-3b2d02a9d121;
Path=/mhrx; HttpOnly]
... some of my own debugging
2012-06-07 15:25:29,167 [http-bio-8080-exec-5] DEBUG
org.apache.shiro.web.servlet.SimpleCookie .readValue:366 - Found
'JSESSIONID' cookie value [6ca59e24-d8c8-497c-bcc4-3b2d02a9d121]
I'm not sure it matters, but I do have my own Realm implementation, as well
as my own LoginFilter that extends AuthenticatingFilter. I don't recall
seeing anything in the superclasses that could screw this part up, though.
I'll post back in a little bit with what happens with the expired attempt.
--
View this message in context: http://shiro-user.582556.n2.nabble.com/Native-session-management-for-web-sessions-tp7577474p7577476.html
Sent from the Shiro User mailing list archive at Nabble.com.
Re: Native session management for web sessions
Posted by Les Hazlewood <lh...@apache.org>.
Your INI config looks fine. And yes, I wouldn't use the 'native'
setting anymore.
The DefaultWebSessionManager by default uses a MemorySessionDAO which
stores all sessions 100% in memory, so you shouldn't be losing
anything.
The important lines are here:
org.apache.shiro.session.mgt.DefaultSessionManager .retrieveSession:218 -
Unable to resolve session ID from SessionKey
[org.apache.shiro.web.session.mgt.WebSessionKey@59bd523d]. Returning null
to indicate a session could not be found.
This means that Shiro couldn't obtain a JSESSIONID cookie from the
request. Perhaps something is interfering from the client being able
to set/get the JSESSIONID cookie?
Can you see the JSESSIONID cookie being set in the response header?
Regards,
--
Les Hazlewood
CTO, Stormpath | http://stormpath.com | 888.391.5282
twitter: @lhazlewood | http://twitter.com/lhazlewood
blog: http://leshazlewood.com
stormpath blog: http://www.stormpath.com/blog
On Thu, Jun 7, 2012 at 2:13 PM, drmike01 <ms...@gmail.com> wrote:
> I'm struggling a bit with using native session management in my web
> application, which doesn't seem to be persisting sessions for as long as I
> have configured them.
>
> My shiro.ini is configured with the following relevant lines, and to me this
> seems (based on documentation and forum messages) to be correct. I have a
> very long timeout (72 hrs) because the app is used in an already-secure
> environment, so this is the maximum time required by our regulations
> (basically a CYA thing), and I need to be able to cache the sessions because
> of the length of time.
>
> sessionManager = org.apache.shiro.web.session.mgt.DefaultWebSessionManager
> securityManager.sessionManager = $sessionManager
> securityManager.sessionManager.globalSessionTimeout = 259200000
>
> I also tried adding in securityManager.sessionMode = native, which I saw in
> one comment, but that is apparently deprecated as of 1.2. It made some
> comments in the logs when it started, and seemed okay with that, but I don't
> think it helped.
>
> The problem is that, when I use my application (a web-based mobile app
> wrapped in PhoneGap), the sessions only seem to persist less than 30
> minutes, I haven't really been able to figure out exactly how long, and
> nowhere close to the 72 hrs I have configured. The (hopefully relevant) log
> output looks like this when I start the app:
>
>
> 2012-06-07 13:33:42,841 [pool-3-thread-1] DEBUG
> org.apache.shiro.config.ReflectionBuilder .resolveReference:235 -
> Encountered object reference '$sessionManager'. Looking up object with id
> 'sessionManager'
> 2012-06-07 13:33:42,845 [pool-3-thread-1] DEBUG
> org.apache.commons.beanutils.ConvertUtils .convert:460 - Convert string
> '259200000' to class 'long'
> 2012-06-07 13:33:42,845 [pool-3-thread-1] DEBUG
> org.apache.commons.beanutils.converters.LongConverter .convert:127 -
> Converting 'String' value '259200000' to type 'Long'
> 2012-06-07 13:33:42,845 [pool-3-thread-1] DEBUG
> org.apache.commons.beanutils.converters.LongConverter .convertToType:266 -
> No NumberFormat, using default conversion
> 2012-06-07 13:33:42,845 [pool-3-thread-1] DEBUG
> org.apache.commons.beanutils.converters.LongConverter .convert:158 -
> Converted to Long value '259200000'
> 2012-06-07 13:33:42,846 [pool-3-thread-1] DEBUG
> org.apache.shiro.realm.AuthorizingRealm .getAuthorizationCacheLazy:234 - No
> authorizationCache instance set. Checking for a cacheManager...
> 2012-06-07 13:33:42,846 [pool-3-thread-1] INFO
> org.apache.shiro.realm.AuthorizingRealm .getAuthorizationCacheLazy:248 - No
> cache or cacheManager properties have been set. Authorization cache cannot
> be obtained.
>
> And when I try to access the app after the timeout has occurred:
>
> 2012-06-07 11:12:50,181 [http-bio-8080-exec-2] DEBUG
> org.apache.shiro.session.mgt.DefaultSessionManager .retrieveSession:218 -
> Unable to resolve session ID from SessionKey
> [org.apache.shiro.web.session.mgt.WebSessionKey@59bd523d]. Returning null
> to indicate a session could not be found.
> 2012-06-07 11:12:50,182 [http-bio-8080-exec-2] DEBUG
> org.apache.shiro.web.servlet.SimpleCookie .readValue:366 - Found
> 'rememberMe' cookie value
> [ex//hFAQh3oCzHKpoRYmo93Wb2ufljgur+iSqXWvIGQIE5N8P8iqdetF+wIYWW+YOwd5Db+UkDjl4YIOv+8HOY6BQb1tf3hfTYoR7GMP+1m7/4ef3d1mf2SWxIbQeOxS1EAOb0q6GlQMaqg+Aj3G4FtBPSdiTMgk+74eeB3ogAHWDoniKKyuauuduGs/8bBOBrP30HaGutKOhgK21HNlndFmdwDtcbFHVQE8wrBfhpJH/g0aSu4eCPVkeMwKzfJtF+a2Fv6vQx15jMWJt6i6jd7HPTWTUaKoUjg7mnCtx13f9BqRa0+Feh+YZVIRNyXuHpO4lDCEXQdVSYsN3HfXg+hAA/HQHxc06HhScIDxeD0LfO6PsOBIFebWTflwmxBiFBI+z3IRLEXnnFOU45MBrVbrCE1a84G3YGwCCeoUf9rAX4OMiTWMV50izqQZOo/e88QxQxhhfNyhtbpBOLbtOBoZErgEpQSO94VvRCZ6xpLyE+v8NX4fzASY9Q4ZCmalTE0r6XwOiN1bsUGwfzuURQ]
> 2012-06-07 11:12:50,182 [http-bio-8080-exec-2] DEBUG
> org.apache.shiro.mgt.DefaultSecurityManager .resolvePrincipals:495 - Found
> remembered PrincipalCollection. Adding to the context to be used for
> subject construction by the SubjectFactory.
> 2012-06-07 11:12:50,182 [http-bio-8080-exec-2] DEBUG
> org.apache.shiro.session.mgt.DefaultSessionManager .create:175 - Creating
> new EIS record for new session instance
> [org.apache.shiro.session.mgt.SimpleSession,id=null]
>
> Based on these logs, what it seems to me is that it isn't caching at all,
> even in memory, and therefore can't find sessions when whatever session it
> is looking at expires. It is, however, storing cookies, so that's happening
> okay. It acts like it's using the servlet containers sessions, but I don't
> see how it could with that configuration. I've also seen a bunch of logs
> that suggest it does session clean-ups, but it never seems to find any; that
> may not be related.
>
> Thank you in advance for any insight on this one. I'm kind of stumped.
>
> --
> View this message in context: http://shiro-user.582556.n2.nabble.com/Native-session-management-for-web-sessions-tp7577474.html
> Sent from the Shiro User mailing list archive at Nabble.com.