Race condition between Session.touch() and AbstractValidatingSessionManager.

[smm <st...@hcs.us.com>]

I think I've found a race condition using Shiro 1.3.0 and a trivial web
application between Session.touch() and the
AbstractValidatingSessionManager.validateSessions().  The reason I'm looking
that this code so carefully for race conditions is that our production web
site sees the occasional (a few a week) UnknownSessionException in a way
that is likely presenting the user with a 500 error screen.

I set my breakpoints at SimpleSession.touch() and
AbstractValidatingSessionManager.validateSession().

Here are the steps to reproduce:
1) I login, which creates my session and takes me to my default Servlet/JSP.
2) I refresh my web page, which will hit the Servlet again, but I stop at
the "touch" breakpoint.
3) I wait for the ExecutorServiceSessionValidationScheduler to hit my
breakpoint in AbstractValidatingSessionManager.
4) Step through and let AbstractValidatingSessionManager.validateSession()
invalidate my session and delete it because it is expired.
5) Resume at the "touch" breakpoint and I get a 500 error page with
UnknownSessionException:

It really seems like there could be a race condition were a user reloads a
web page right as their session is expiring.  The user get the session, but
the ExecutorServiceSessionValidationScheduler immediately invalidates it
before the user can "touch" it.  This results in the Servlet failing if it
needs something out the Session (such as the Principal - it has no problem
retrieving the Subject). 

Here is my shiro.ini file:


As you can see, the only custom code I'm using is the TestRealm, which
authenticates anyone who provides a username and password.

Here is my trivial Servlet:



It fails on "subject.getPrincipal()" in the scenario described above and has
been seen to fail in my production code in a similar line with a similar
error message.

Here is the exception:


Am I missing something or is there really a race condition here?

If there is not a race condition, is there another good explanation for why
I'm sometimes seeing UnknownSessionExceptions in my production code when
fetching a Subject's Principals?

Note: My trivial test case uses Shiro 1.3.0 code while my production code is
using 1.2.2.

Thanks!

--Stephen



--
View this message in context: http://shiro-user.582556.n2.nabble.com/Race-condition-between-Session-touch-and-AbstractValidatingSessionManager-tp7581196.html
Sent from the Shiro User mailing list archive at Nabble.com.

Re: Race condition between Session.touch() and AbstractValidatingSessionManager.

[smm <st...@hcs.us.com>]

Opened as  SHIRO-578 <https://issues.apache.org/jira/browse/SHIRO-578>  .



--
View this message in context: http://shiro-user.582556.n2.nabble.com/Race-condition-between-Session-touch-and-AbstractValidatingSessionManager-tp7581196p7581199.html
Sent from the Shiro User mailing list archive at Nabble.com.

Re: Race condition between Session.touch() and AbstractValidatingSessionManager.

[Lenny Primak <lp...@hope.nyc.ny.us>]

It is not out of realm of possibility. I've experienced race condition just once in production but it wasn't exactly like yours, but from what you are describing it's entirely possible. You should file a JIRA issue. 

> On Jul 29, 2016, at 6:42 PM, smm <st...@hcs.us.com> wrote:
> 
> I think I've found a race condition using Shiro 1.3.0 and a trivial web
> application between Session.touch() and the
> AbstractValidatingSessionManager.validateSessions().  The reason I'm looking
> that this code so carefully for race conditions is that our production web
> site sees the occasional (a few a week) UnknownSessionException in a way
> that is likely presenting the user with a 500 error screen.
> 
> I set my breakpoints at SimpleSession.touch() and
> AbstractValidatingSessionManager.validateSession().
> 
> Here are the steps to reproduce:
> 1) I login, which creates my session and takes me to my default Servlet/JSP.
> 2) I refresh my web page, which will hit the Servlet again, but I stop at
> the "touch" breakpoint.
> 3) I wait for the ExecutorServiceSessionValidationScheduler to hit my
> breakpoint in AbstractValidatingSessionManager.
> 4) Step through and let AbstractValidatingSessionManager.validateSession()
> invalidate my session and delete it because it is expired.
> 5) Resume at the "touch" breakpoint and I get a 500 error page with
> UnknownSessionException:
> 
> It really seems like there could be a race condition were a user reloads a
> web page right as their session is expiring.  The user get the session, but
> the ExecutorServiceSessionValidationScheduler immediately invalidates it
> before the user can "touch" it.  This results in the Servlet failing if it
> needs something out the Session (such as the Principal - it has no problem
> retrieving the Subject). 
> 
> Here is my shiro.ini file:
> 
> 
> As you can see, the only custom code I'm using is the TestRealm, which
> authenticates anyone who provides a username and password.
> 
> Here is my trivial Servlet:
> 
> 
> 
> It fails on "subject.getPrincipal()" in the scenario described above and has
> been seen to fail in my production code in a similar line with a similar
> error message.
> 
> Here is the exception:
> 
> 
> Am I missing something or is there really a race condition here?
> 
> If there is not a race condition, is there another good explanation for why
> I'm sometimes seeing UnknownSessionExceptions in my production code when
> fetching a Subject's Principals?
> 
> Note: My trivial test case uses Shiro 1.3.0 code while my production code is
> using 1.2.2.
> 
> Thanks!
> 
> --Stephen
> 
> 
> 
> --
> View this message in context: http://shiro-user.582556.n2.nabble.com/Race-condition-between-Session-touch-and-AbstractValidatingSessionManager-tp7581196.html
> Sent from the Shiro User mailing list archive at Nabble.com.
>