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