[jira] [Comment Edited] (SHIRO-512) Race condition in Shiro's web container session timeout handling

["Richard Adams (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/SHIRO-512?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16193222#comment-16193222 ] 

Richard Adams edited comment on SHIRO-512 at 10/5/17 5:20 PM:
--------------------------------------------------------------

Don't know if this is related but I occasionally see the same exception when running background jobs launched through a REST -API call with {{noSessionCreation}} set to true. In brief:
# Client submits POST request to launch long-running job, using an API key in the header to authenticate
# Server authenticates( we can identify a Shiro subject from the key) and logs them in for the duration of the call
# Server creates a new job to run in background. Subject is bound to this background thread
# Server returns quickly, logging out the subject, with a response containing a job  id to query job progress
# Some time later, the job starts. While the job is running, it has to do some permissions authorisation, calling exactly the same stack as listed above. Most of the time it works, but occasionally I get this stack trace. I am puzzled as there should not be any session created at all - the user is not logged into the web application while making the API call for example.

I am using Java 8, Tomcat 7.054, Spring 4.3.1 and Shiro 1.4.0. I have tried exploring the relative timing of when the initial request returns, and when the job is launched, and no combination reproduces this error deterministically. E.g. 
* pausing job in debug mode to ensure initial submission post request returns before permissions lookups
* pausing return from initial post to ensure job starts before initial request is logged out.

Here is the code in  a Spring Interceptor which wraps round each  api request:
pre request: {{SecurityUtils.getSubject().login(new ApiKeyAuthenticationToken(u.getUsername(), apiKey));}}
post request: {{SecurityUtils.getSubject().logout();}}

Thanks for any help on this or if anyone else has got this stack trace.
I would say that I only see this on Tomcat, never on Jetty, have no idea if this is relevant.

Richard

 


was (Author: otter606):
Don't know if this is related but I occasionally see the same exception when running background jobs launched through a REST -API call with {{noSessionCreation}} set to true. In brief:
# Client submits POST request to launch long-running job, using an API key in the header to authenticate
# Server authenticates( we can identify a Shiro subject from the key) and logs them in for the duration of the call
# Server creates a new job to run in background. Subject is bound to this background thread
# Server returns quickly, logging out the subject, with a response containing a job  id to query job progress
# Some time later, the job starts. While the job is running, it has to do some permissions authorisation, calling exactly the same stack as listed above. Most of the time it works, but occasionally I get this stack trace. I am puzzled as there should not be any session created at all - the user is not logged into the web application while making the API call for example.

I am using Java 8, Tomcat 7.054, Spring 4.3.1 and Shiro 1.4.0. I have tried exploring the relative timing of when the initial request returns, and when the job is launched, and no combination reproduces this error deterministically. E.g. 
* pausing job in debug mode to ensure initial submission post request returns before permissions lookups
* pausing return from initial post to ensure job starts before initial request is logged out.

Here is the code in  a Spring Interceptor which wraps round each  api request:
pre request: {{SecurityUtils.getSubject().login(new ApiKeyAuthenticationToken(u.getUsername(), apiKey));}}
post request: {{SecurityUtils.getSubject().logout();}}

Thanks for any help on this or if anyone else has got this stack trace

Richard

 

> Race condition in Shiro's web container session timeout handling
> ----------------------------------------------------------------
>
>                 Key: SHIRO-512
>                 URL: https://issues.apache.org/jira/browse/SHIRO-512
>             Project: Shiro
>          Issue Type: Bug
>          Components: Authentication (log-in)
>    Affects Versions: 1.2.2, 1.2.3
>            Reporter: Lenny Primak
>            Priority: Minor
>
> I cannot find anywhere that Shiro uses HttpSessionListener to trap sessionDestroyed event from the container. 
> I believe this is leading to a rare race condition in my application, as Shiro thinks the session is still active, 
> but in reality, the web session has been destroyed. 
> Code:  SecurityUtils.getSubject().getPrincipal(); 
> Relevant bit of stack trace: 
> Caused by: org.apache.shiro.session.InvalidSessionException: java.lang.IllegalStateException: PWC2778: getAttribute: Session already invalidated 
>         at org.apache.shiro.web.session.HttpServletSession.getAttribute(HttpServletSession.java:148) 
>         at org.apache.shiro.session.ProxiedSession.getAttribute(ProxiedSession.java:121) 
>         at org.apache.shiro.subject.support.DelegatingSubject.getRunAsPrincipalsStack(DelegatingSubject.java:469) 
>         at org.apache.shiro.subject.support.DelegatingSubject.getPrincipals(DelegatingSubject.java:153) 
>         at org.apache.shiro.subject.support.DelegatingSubject.getPrincipal(DelegatingSubject.java:149) 
> Link to the mailing list thread: 
> http://shiro-user.582556.n2.nabble.com/Possible-race-condition-in-Shiro-s-web-container-session-timeout-handling-td7580138.html



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)