You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@shiro.apache.org by Patrick Schwarzer <Pa...@tomtec.de> on 2019/04/11 07:55:32 UTC
WG: Problem with ShiroHttpServletRequest.getSession when session
dies
Dear Sir or Madam,
we have a problem with https://github.com/apache/shiro/pull/72/files and see communication with Apache Wicket team below.
We thought the bug fix is already included in Apache Shiro 1.4, but it isn't.
Can you tell me, when a new version of Apache Shiro will be released that contains the bug fix?
Kind regards
PATRICK SCHWARZER
SOFTWARE ENGINEER
o +49 89 32175 655
TOMTEC Imaging Systems GmbH
Edisonstrasse 6, 85716 Unterschleissheim, Germany, Managing Director:
Johannes Waldinger, Dr. Thomas Piehler, HRB 235646 Amtsgericht Muenchen
[cid:image003.jpg@01D4EAC5.E4FEFCC0]<http://www.tomtec.de/>
Hi Martin,
thanks for the explanation.
After some further research we identified the reason for the problem. Shiro 1.3.2 has a bug, explained here: https://issues.apache.org/jira/browse/SHIRO-637.
In case, there is no session any more, Shiro calls to getSession(false) returned a cached Session instead of returning null. This problem is fixed with 1.4.
We will update Shiro to fix this problem.
Thanks for your help.
Kind regards
PATRICK SCHWARZER
SOFTWARE ENGINEER
o +49 89 32175 655
TOMTEC Imaging Systems GmbH
Edisonstrasse 6, 85716 Unterschleissheim, Germany, Managing Director:
Johannes Waldinger, Dr. Thomas Piehler, HRB 235646 Amtsgericht Muenchen
[cid:image001.jpg@01D4EAF3.85ED4920]<http://www.tomtec.de/>
Hi Patrick,
On Thu, Apr 4, 2019 at 10:16 AM Patrick Schwarzer <
Patrick.Schwarzer@tomtec.de<ma...@tomtec.de>> wrote:
> Hi Sven,
>
>
>
> thanks for the reply.
>
>
>
> The problem is, that at the end of the request in onDetach wicket tries to
> write content of pages into the session (see storeTouchedPages in
> Stack-Trace), which is already dead. To identify if wicket needs to store
> content into session, it checked the Session.get() /
> ThreadContext.getSession() cached Session, which represents not the real
> last state of the session.
>
>
>
> When wicket then writes content into session, it look in the real dead
> session (getSessionStore().getAttribute call).
>
I have the feeling there is some problem with Shiro here.
What exactly is a "dead" session ?!
Wicket uses HttpServletRequest#getSession(boolean) to get the underlying
HttpSession.
Depending on the value of the boolean parameter the Servlet container
should:
- if the parameter is 'false' then:
-- if there is a session then it should return it
-- if there is a no session then it should return null
- if the value is 'true' then:
-- if there is a session then it should return it
-- if there is a no session then it should create a *new* HttpSession and
return it
So, I do not understand what Shiro considers as "dead" session.
>
> So I don't know the right solution but I could not understand why checking
> state of session is done on a cached version while writing than is done on
> the real one. Does the process not to be consistent (check and write in the
> cached or check and write in the real one)?
>
Wicket stores the Wicket Session into a ThreadLocal, i.e. caches it. But
any access to the HttpSession is via HttpSessionStore which uses the
Servlet APIs.
The Wicket Session itself is stored as an attribute in the HttpSession.
Martin Grigorov
Von: Patrick Schwarzer
Gesendet: Donnerstag, 4. April 2019 09:13
An: 'users@wicket.apache.org' <us...@wicket.apache.org>>
Betreff: Re: Problem with ThreadContext.getSession when session dies
Hi Sven,
thanks for the reply.
The problem is, that at the end of the request in onDetach wicket tries to write content of pages into the session (see storeTouchedPages in Stack-Trace), which is already dead. To identify if wicket needs to store content into session, it checked the Session.get() / ThreadContext.getSession() cached Session, which represents not the real last state of the session.
When wicket then writes content into session, it look in the real dead session (getSessionStore().getAttribute call).
So I don't know the right solution but I could not understand why checking state of session is done on a cached version while writing than is done on the real one. Does the process not to be consistent (check and write in the cached or check and write in the real one)?
Kind regards
PATRICK SCHWARZER
SOFTWARE ENGINEER
o +49 89 32175 655
TOMTEC Imaging Systems GmbH
Edisonstrasse 6, 85716 Unterschleissheim, Germany, Managing Director:
Johannes Waldinger, Dr. Thomas Piehler, HRB 235646 Amtsgericht Muenchen
[cid:image003.jpg@01D4EAC5.E4FEFCC0]<http://www.tomtec.de/>
Hi Patrick,
Wicket uses a temporary session if there's no container session, e.g.
the latter has already expired.
It's not clear to me why that's a problem for you.
Best regards
Sven
Von: Patrick Schwarzer
Gesendet: Mittwoch, 3. April 2019 13:27
An: 'users@wicket.apache.org' <us...@wicket.apache.org>>
Betreff: Problem with ThreadContext.getSession when session dies
Dear Sir or Madam,
we identified an issue during request handling in Wicket 7.12.0 when session dies during processing.
The problem is, that parts of the code accessing current session by calling Session.get() which then return a valid session cached in ThreadContext.getSession().
[cid:image004.png@01D4EAC5.E4FEFCC0]
But when accessing an attribute of the Session, the code accesses the real session, which is dead and leads to an Exception.
[cid:image005.png@01D4EAC5.E4FEFCC0]
So we were a little confused why Session.get() and Session.exists() return valid results when Session is already dead.
How we can avoid Session.get() and Session.exists() return valid results? Alternatively how we can ensure, that Request with cached Session is handled correctly?
The stack trace of our problem:
java.lang.IllegalStateException: org.apache.shiro.session.UnknownSessionException: There is no session with id [48cf6f39-9bf6-4b76-84cd-a106e707af63]
at org.apache.shiro.web.servlet.ShiroHttpSession.getAttribute(ShiroHttpSession.java:133) ~[shiro-web-1.3.2.jar:1.3.2]
getAttribute:286, HttpSessionStore (org.apache.wicket.session)
getAttribute:743, Session (org.apache.wicket) << Why this is not accessing cached Session?
getSessionAttribute:66, DefaultPageManagerContext (org.apache.wicket.page)
getSessionAttribute:101, RequestAdapter (org.apache.wicket.page)
getSessionEntry:414, PageStoreManager$PersistentRequestAdapter (org.apache.wicket.page)
storeTouchedPages:438, PageStoreManager$PersistentRequestAdapter (org.apache.wicket.page) << Should this happen, when Session is already dead?
commitRequest:193, RequestAdapter (org.apache.wicket.page)
commitRequest:76, AbstractPageManager (org.apache.wicket.page)
commitRequest:74, PageManagerDecorator (org.apache.wicket.page)
commitRequest:270, PageAccessSynchronizer$2 (org.apache.wicket.page)
onDetach:1798, Application$3 (org.apache.wicket)
notify:105, RequestCycleListenerCollection$3 (org.apache.wicket.request.cycle)
notify:101, RequestCycleListenerCollection$3 (org.apache.wicket.request.cycle)
notify:120, ListenerCollection$1 (org.apache.wicket.util.listener)
reversedNotify:144, ListenerCollection (org.apache.wicket.util.listener)
reversedNotifyIgnoringExceptions:113, ListenerCollection (org.apache.wicket.util.listener)
onDetach:100, RequestCycleListenerCollection (org.apache.wicket.request.cycle)
onDetach:649, RequestCycle (org.apache.wicket.request.cycle)
detach:594, RequestCycle (org.apache.wicket.request.cycle)
processRequestAndDetach:297, RequestCycle (org.apache.wicket.request.cycle)
processRequestCycle:261, WicketFilter (org.apache.wicket.protocol.http)
processRequest:203, WicketFilter (org.apache.wicket.protocol.http)
doFilter:284, WicketFilter (org.apache.wicket.protocol.http)
internalDoFilter:193, ApplicationFilterChain (org.apache.catalina.core)
doFilter:166, ApplicationFilterChain (org.apache.catalina.core)
doFilterInternal:99, RequestContextFilter (org.springframework.web.filter)
doFilter:107, OncePerRequestFilter (org.springframework.web.filter)
internalDoFilter:193, ApplicationFilterChain (org.apache.catalina.core)
doFilter:166, ApplicationFilterChain (org.apache.catalina.core)
doFilter:61, ProxiedFilterChain (org.apache.shiro.web.servlet)
executeChain:108, AdviceFilter (org.apache.shiro.web.servlet)
doFilterInternal:137, AdviceFilter (org.apache.shiro.web.servlet)
doFilter:125, OncePerRequestFilter (org.apache.shiro.web.servlet)
doFilter:66, ProxiedFilterChain (org.apache.shiro.web.servlet)
executeChain:108, AdviceFilter (org.apache.shiro.web.servlet)
doFilterInternal:137, AdviceFilter (org.apache.shiro.web.servlet)
doFilter:125, OncePerRequestFilter (org.apache.shiro.web.servlet)
doFilter:66, ProxiedFilterChain (org.apache.shiro.web.servlet)
executeChain:449, AbstractShiroFilter (org.apache.shiro.web.servlet)
call:365, AbstractShiroFilter$1 (org.apache.shiro.web.servlet)
doCall:90, SubjectCallable (org.apache.shiro.subject.support)
call:83, SubjectCallable (org.apache.shiro.subject.support)
execute:383, DelegatingSubject (org.apache.shiro.subject.support)
doFilterInternal:362, AbstractShiroFilter (org.apache.shiro.web.servlet)
doFilter:125, OncePerRequestFilter (org.apache.shiro.web.servlet)
invokeDelegate:357, DelegatingFilterProxy (org.springframework.web.filter)
doFilter:270, DelegatingFilterProxy (org.springframework.web.filter)
internalDoFilter:193, ApplicationFilterChain (org.apache.catalina.core)
doFilter:166, ApplicationFilterChain (org.apache.catalina.core)
invoke:198, StandardWrapperValve (org.apache.catalina.core)
invoke:96, StandardContextValve (org.apache.catalina.core)
invoke:478, AuthenticatorBase (org.apache.catalina.authenticator)
invoke:140, StandardHostValve (org.apache.catalina.core)
invoke:80, ErrorReportValve (org.apache.catalina.valves)
invoke:650, AbstractAccessLogValve (org.apache.catalina.valves)
invoke:279, RewriteValve (org.apache.catalina.valves.rewrite)
invoke:677, RemoteIpValve (org.apache.catalina.valves)
invoke:87, StandardEngineValve (org.apache.catalina.core)
service:342, CoyoteAdapter (org.apache.catalina.connector)
service:799, Http11Processor (org.apache.coyote.http11)
process:66, AbstractProcessorLight (org.apache.coyote)
process:868, AbstractProtocol$ConnectionHandler (org.apache.coyote)
doRun:1457, NioEndpoint$SocketProcessor (org.apache.tomcat.util.net)
run:49, SocketProcessorBase (org.apache.tomcat.util.net)
runWorker:1149, ThreadPoolExecutor (java.util.concurrent)
run:624, ThreadPoolExecutor$Worker (java.util.concurrent)
run:61, TaskThread$WrappingRunnable (org.apache.tomcat.util.threads)
run:748, Thread (java.lang)
Kind regards
PATRICK SCHWARZER
SOFTWARE ENGINEER
o +49 89 32175 655
TOMTEC Imaging Systems GmbH
Edisonstrasse 6, 85716 Unterschleissheim, Germany, Managing Director:
Johannes Waldinger, Dr. Thomas Piehler, HRB 235646 Amtsgericht Muenchen
[cid:image003.jpg@01D4EAC5.E4FEFCC0]<http://www.tomtec.de/>
AW: WG: Problem with ShiroHttpServletRequest.getSession when
session dies
Posted by Patrick Schwarzer <Pa...@tomtec.de>.
Hi Francois,
thanks for the fast reply.
That sounds great, than we wait for the new release.
Thanks a lot.
Kind regards
PATRICK SCHWARZER
SOFTWARE ENGINEER
o +49 89 32175 655
TOMTEC Imaging Systems GmbH
Edisonstrasse 6, 85716 Unterschleissheim, Germany, Managing Director:
Johannes Waldinger, Dr. Thomas Piehler, HRB 235646 Amtsgericht Muenchen
[cid:image001.jpg@01D4F04F.4842B180]<http://www.tomtec.de/>
Von: Francois Papon [mailto:francois.papon@openobject.fr]
Gesendet: Donnerstag, 11. April 2019 10:08
An: user@shiro.apache.org
Betreff: Re: WG: Problem with ShiroHttpServletRequest.getSession when session dies
Hi Patrick,
This issues was merged on master and is included in the next 1.4.1 release.
You can see the release note here:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310950&version=12344826
We will do our best to release the 1.4.1 before the end of april.
regards,
François Papon
fpapon@apache.org<ma...@apache.org>
Le 11/04/2019 à 11:55, Patrick Schwarzer a écrit :
Dear Sir or Madam,
we have a problem with https://github.com/apache/shiro/pull/72/files and see communication with Apache Wicket team below.
We thought the bug fix is already included in Apache Shiro 1.4, but it isn't.
Can you tell me, when a new version of Apache Shiro will be released that contains the bug fix?
Kind regards
PATRICK SCHWARZER
SOFTWARE ENGINEER
o +49 89 32175 655
TOMTEC Imaging Systems GmbH
Edisonstrasse 6, 85716 Unterschleissheim, Germany, Managing Director:
Johannes Waldinger, Dr. Thomas Piehler, HRB 235646 Amtsgericht Muenchen
[cid:image001.jpg@01D4F04F.4842B180]<http://www.tomtec.de/>
Hi Martin,
thanks for the explanation.
After some further research we identified the reason for the problem. Shiro 1.3.2 has a bug, explained here: https://issues.apache.org/jira/browse/SHIRO-637.
In case, there is no session any more, Shiro calls to getSession(false) returned a cached Session instead of returning null. This problem is fixed with 1.4.
We will update Shiro to fix this problem.
Thanks for your help.
Kind regards
PATRICK SCHWARZER
SOFTWARE ENGINEER
o +49 89 32175 655
TOMTEC Imaging Systems GmbH
Edisonstrasse 6, 85716 Unterschleissheim, Germany, Managing Director:
Johannes Waldinger, Dr. Thomas Piehler, HRB 235646 Amtsgericht Muenchen
[cid:image001.jpg@01D4EAF3.85ED4920]<http://www.tomtec.de/>
Hi Patrick,
On Thu, Apr 4, 2019 at 10:16 AM Patrick Schwarzer <
Patrick.Schwarzer@tomtec.de<ma...@tomtec.de>> wrote:
> Hi Sven,
>
>
>
> thanks for the reply.
>
>
>
> The problem is, that at the end of the request in onDetach wicket tries to
> write content of pages into the session (see storeTouchedPages in
> Stack-Trace), which is already dead. To identify if wicket needs to store
> content into session, it checked the Session.get() /
> ThreadContext.getSession() cached Session, which represents not the real
> last state of the session.
>
>
>
> When wicket then writes content into session, it look in the real dead
> session (getSessionStore().getAttribute call).
>
I have the feeling there is some problem with Shiro here.
What exactly is a "dead" session ?!
Wicket uses HttpServletRequest#getSession(boolean) to get the underlying
HttpSession.
Depending on the value of the boolean parameter the Servlet container
should:
- if the parameter is 'false' then:
-- if there is a session then it should return it
-- if there is a no session then it should return null
- if the value is 'true' then:
-- if there is a session then it should return it
-- if there is a no session then it should create a *new* HttpSession and
return it
So, I do not understand what Shiro considers as "dead" session.
>
> So I don't know the right solution but I could not understand why checking
> state of session is done on a cached version while writing than is done on
> the real one. Does the process not to be consistent (check and write in the
> cached or check and write in the real one)?
>
Wicket stores the Wicket Session into a ThreadLocal, i.e. caches it. But
any access to the HttpSession is via HttpSessionStore which uses the
Servlet APIs.
The Wicket Session itself is stored as an attribute in the HttpSession.
Martin Grigorov
Von: Patrick Schwarzer
Gesendet: Donnerstag, 4. April 2019 09:13
An: 'users@wicket.apache.org<ma...@wicket.apache.org>' <us...@wicket.apache.org>>
Betreff: Re: Problem with ThreadContext.getSession when session dies
Hi Sven,
thanks for the reply.
The problem is, that at the end of the request in onDetach wicket tries to write content of pages into the session (see storeTouchedPages in Stack-Trace), which is already dead. To identify if wicket needs to store content into session, it checked the Session.get() / ThreadContext.getSession() cached Session, which represents not the real last state of the session.
When wicket then writes content into session, it look in the real dead session (getSessionStore().getAttribute call).
So I don't know the right solution but I could not understand why checking state of session is done on a cached version while writing than is done on the real one. Does the process not to be consistent (check and write in the cached or check and write in the real one)?
Kind regards
PATRICK SCHWARZER
SOFTWARE ENGINEER
o +49 89 32175 655
TOMTEC Imaging Systems GmbH
Edisonstrasse 6, 85716 Unterschleissheim, Germany, Managing Director:
Johannes Waldinger, Dr. Thomas Piehler, HRB 235646 Amtsgericht Muenchen
[imap://francois%2Epapon%40openobject%2Efr@imap.1und1.de:993/fetch%3EUID%3E/INBOX/apache/shiro%3E824?header=quotebody&part=1.2&filename=image003.jpg]<http://www.tomtec.de/>
Hi Patrick,
Wicket uses a temporary session if there's no container session, e.g.
the latter has already expired.
It's not clear to me why that's a problem for you.
Best regards
Sven
Von: Patrick Schwarzer
Gesendet: Mittwoch, 3. April 2019 13:27
An: 'users@wicket.apache.org<ma...@wicket.apache.org>' <us...@wicket.apache.org>>
Betreff: Problem with ThreadContext.getSession when session dies
Dear Sir or Madam,
we identified an issue during request handling in Wicket 7.12.0 when session dies during processing.
The problem is, that parts of the code accessing current session by calling Session.get() which then return a valid session cached in ThreadContext.getSession().
[imap://francois%2Epapon%40openobject%2Efr@imap.1und1.de:993/fetch%3EUID%3E/INBOX/apache/shiro%3E824?header=quotebody&part=1.3&filename=image004.png]
But when accessing an attribute of the Session, the code accesses the real session, which is dead and leads to an Exception.
[imap://francois%2Epapon%40openobject%2Efr@imap.1und1.de:993/fetch%3EUID%3E/INBOX/apache/shiro%3E824?header=quotebody&part=1.4&filename=image005.png]
So we were a little confused why Session.get() and Session.exists() return valid results when Session is already dead.
How we can avoid Session.get() and Session.exists() return valid results? Alternatively how we can ensure, that Request with cached Session is handled correctly?
The stack trace of our problem:
java.lang.IllegalStateException: org.apache.shiro.session.UnknownSessionException: There is no session with id [48cf6f39-9bf6-4b76-84cd-a106e707af63]
at org.apache.shiro.web.servlet.ShiroHttpSession.getAttribute(ShiroHttpSession.java:133) ~[shiro-web-1.3.2.jar:1.3.2]
getAttribute:286, HttpSessionStore (org.apache.wicket.session)
getAttribute:743, Session (org.apache.wicket) << Why this is not accessing cached Session?
getSessionAttribute:66, DefaultPageManagerContext (org.apache.wicket.page)
getSessionAttribute:101, RequestAdapter (org.apache.wicket.page)
getSessionEntry:414, PageStoreManager$PersistentRequestAdapter (org.apache.wicket.page)
storeTouchedPages:438, PageStoreManager$PersistentRequestAdapter (org.apache.wicket.page) << Should this happen, when Session is already dead?
commitRequest:193, RequestAdapter (org.apache.wicket.page)
commitRequest:76, AbstractPageManager (org.apache.wicket.page)
commitRequest:74, PageManagerDecorator (org.apache.wicket.page)
commitRequest:270, PageAccessSynchronizer$2 (org.apache.wicket.page)
onDetach:1798, Application$3 (org.apache.wicket)
notify:105, RequestCycleListenerCollection$3 (org.apache.wicket.request.cycle)
notify:101, RequestCycleListenerCollection$3 (org.apache.wicket.request.cycle)
notify:120, ListenerCollection$1 (org.apache.wicket.util.listener)
reversedNotify:144, ListenerCollection (org.apache.wicket.util.listener)
reversedNotifyIgnoringExceptions:113, ListenerCollection (org.apache.wicket.util.listener)
onDetach:100, RequestCycleListenerCollection (org.apache.wicket.request.cycle)
onDetach:649, RequestCycle (org.apache.wicket.request.cycle)
detach:594, RequestCycle (org.apache.wicket.request.cycle)
processRequestAndDetach:297, RequestCycle (org.apache.wicket.request.cycle)
processRequestCycle:261, WicketFilter (org.apache.wicket.protocol.http)
processRequest:203, WicketFilter (org.apache.wicket.protocol.http)
doFilter:284, WicketFilter (org.apache.wicket.protocol.http)
internalDoFilter:193, ApplicationFilterChain (org.apache.catalina.core)
doFilter:166, ApplicationFilterChain (org.apache.catalina.core)
doFilterInternal:99, RequestContextFilter (org.springframework.web.filter)
doFilter:107, OncePerRequestFilter (org.springframework.web.filter)
internalDoFilter:193, ApplicationFilterChain (org.apache.catalina.core)
doFilter:166, ApplicationFilterChain (org.apache.catalina.core)
doFilter:61, ProxiedFilterChain (org.apache.shiro.web.servlet)
executeChain:108, AdviceFilter (org.apache.shiro.web.servlet)
doFilterInternal:137, AdviceFilter (org.apache.shiro.web.servlet)
doFilter:125, OncePerRequestFilter (org.apache.shiro.web.servlet)
doFilter:66, ProxiedFilterChain (org.apache.shiro.web.servlet)
executeChain:108, AdviceFilter (org.apache.shiro.web.servlet)
doFilterInternal:137, AdviceFilter (org.apache.shiro.web.servlet)
doFilter:125, OncePerRequestFilter (org.apache.shiro.web.servlet)
doFilter:66, ProxiedFilterChain (org.apache.shiro.web.servlet)
executeChain:449, AbstractShiroFilter (org.apache.shiro.web.servlet)
call:365, AbstractShiroFilter$1 (org.apache.shiro.web.servlet)
doCall:90, SubjectCallable (org.apache.shiro.subject.support)
call:83, SubjectCallable (org.apache.shiro.subject.support)
execute:383, DelegatingSubject (org.apache.shiro.subject.support)
doFilterInternal:362, AbstractShiroFilter (org.apache.shiro.web.servlet)
doFilter:125, OncePerRequestFilter (org.apache.shiro.web.servlet)
invokeDelegate:357, DelegatingFilterProxy (org.springframework.web.filter)
doFilter:270, DelegatingFilterProxy (org.springframework.web.filter)
internalDoFilter:193, ApplicationFilterChain (org.apache.catalina.core)
doFilter:166, ApplicationFilterChain (org.apache.catalina.core)
invoke:198, StandardWrapperValve (org.apache.catalina.core)
invoke:96, StandardContextValve (org.apache.catalina.core)
invoke:478, AuthenticatorBase (org.apache.catalina.authenticator)
invoke:140, StandardHostValve (org.apache.catalina.core)
invoke:80, ErrorReportValve (org.apache.catalina.valves)
invoke:650, AbstractAccessLogValve (org.apache.catalina.valves)
invoke:279, RewriteValve (org.apache.catalina.valves.rewrite)
invoke:677, RemoteIpValve (org.apache.catalina.valves)
invoke:87, StandardEngineValve (org.apache.catalina.core)
service:342, CoyoteAdapter (org.apache.catalina.connector)
service:799, Http11Processor (org.apache.coyote.http11)
process:66, AbstractProcessorLight (org.apache.coyote)
process:868, AbstractProtocol$ConnectionHandler (org.apache.coyote)
doRun:1457, NioEndpoint$SocketProcessor (org.apache.tomcat.util.net)
run:49, SocketProcessorBase (org.apache.tomcat.util.net)
runWorker:1149, ThreadPoolExecutor (java.util.concurrent)
run:624, ThreadPoolExecutor$Worker (java.util.concurrent)
run:61, TaskThread$WrappingRunnable (org.apache.tomcat.util.threads)
run:748, Thread (java.lang)
Kind regards
PATRICK SCHWARZER
SOFTWARE ENGINEER
o +49 89 32175 655
TOMTEC Imaging Systems GmbH
Edisonstrasse 6, 85716 Unterschleissheim, Germany, Managing Director:
Johannes Waldinger, Dr. Thomas Piehler, HRB 235646 Amtsgericht Muenchen
[imap://francois%2Epapon%40openobject%2Efr@imap.1und1.de:993/fetch%3EUID%3E/INBOX/apache/shiro%3E824?header=quotebody&part=1.2&filename=image003.jpg]<http://www.tomtec.de/>
Re: WG: Problem with ShiroHttpServletRequest.getSession when session
dies
Posted by Francois Papon <fr...@openobject.fr>.
Hi Patrick,
This issues was merged on master and is included in the next 1.4.1 release.
You can see the release note here:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310950&version=12344826
We will do our best to release the 1.4.1 before the end of april.
regards,
François Papon
fpapon@apache.org
Le 11/04/2019 à 11:55, Patrick Schwarzer a écrit :
>
> Dear Sir or Madam,
>
> we have a problem with https://github.com/apache/shiro/pull/72/files
> and see communication with Apache Wicket team below.
>
> We thought the bug fix is already included in Apache Shiro 1.4, but it
> isn’t.
> Can you tell me, when a new version of Apache Shiro will be released
> that contains the bug fix?
>
> Kind regards
>
>
>
> *PATRICK SCHWARZER*
> SOFTWARE ENGINEER
>
> *o***+49 89 32175 655
>
> *TOMTEC Imaging Systems GmbH*
> Edisonstrasse 6, 85716 Unterschleissheim, Germany, Managing Director:
> Johannes Waldinger, Dr. Thomas Piehler, HRB 235646 Amtsgericht Muenchen
>
> ** <http://www.tomtec.de/>
>
>
>
>
>
> Hi Martin,
>
>
>
> thanks for the explanation.
>
>
>
> After some further research we identified the reason for the problem.
> Shiro 1.3.2 has a bug, explained here:
> https://issues.apache.org/jira/browse/SHIRO-637.
>
>
>
> In case, there is no session any more, Shiro calls to
> getSession(false) returned a cached Session instead of returning null.
> This problem is fixed with 1.4.
>
> We will update Shiro to fix this problem.
>
>
>
> Thanks for your help.
>
>
>
> Kind regards
>
>
>
> *PATRICK SCHWARZER*
> SOFTWARE ENGINEER
>
> *o***+49 89 32175 655
>
> *TOMTEC Imaging Systems GmbH*
> Edisonstrasse 6, 85716 Unterschleissheim, Germany, Managing Director:
> Johannes Waldinger, Dr. Thomas Piehler, HRB 235646 Amtsgericht Muenchen
>
> *cid:image001.jpg@01D4EAF3.85ED4920* <http://www.tomtec.de/>
>
> Hi Patrick,
>
>
>
> On Thu, Apr 4, 2019 at 10:16 AM Patrick Schwarzer <
>
> Patrick.Schwarzer@tomtec.de <ma...@tomtec.de>> wrote:
>
>
>
> > Hi Sven,
>
> >
>
> >
>
> >
>
> > thanks for the reply.
>
> >
>
> >
>
> >
>
> > The problem is, that at the end of the request in onDetach wicket
> tries to
>
> > write content of pages into the session (see storeTouchedPages in
>
> > Stack-Trace), which is already dead. To identify if wicket needs to store
>
> > content into session, it checked the Session.get() /
>
> > ThreadContext.getSession() cached Session, which represents not the real
>
> > last state of the session.
>
> >
>
> >
>
> >
>
> > When wicket then writes content into session, it look in the real dead
>
> > session (getSessionStore().getAttribute call).
>
> >
>
>
>
> I have the feeling there is some problem with Shiro here.
>
> What exactly is a "dead" session ?!
>
> Wicket uses HttpServletRequest#getSession(boolean) to get the underlying
>
> HttpSession.
>
> Depending on the value of the boolean parameter the Servlet container
>
> should:
>
> - if the parameter is 'false' then:
>
> -- if there is a session then it should return it
>
> -- if there is a no session then it should return null
>
> - if the value is 'true' then:
>
> -- if there is a session then it should return it
>
> -- if there is a no session then it should create a *new* HttpSession and
>
> return it
>
>
>
> So, I do not understand what Shiro considers as "dead" session.
>
>
>
>
>
> >
>
> > So I don’t know the right solution but I could not understand why
> checking
>
> > state of session is done on a cached version while writing than is
> done on
>
> > the real one. Does the process not to be consistent (check and write
> in the
>
> > cached or check and write in the real one)?
>
> >
>
>
>
> Wicket stores the Wicket Session into a ThreadLocal, i.e. caches it. But
>
> any access to the HttpSession is via HttpSessionStore which uses the
>
> Servlet APIs.
>
> The Wicket Session itself is stored as an attribute in the HttpSession.
>
>
>
> Martin Grigorov
>
>
>
> *Von:*Patrick Schwarzer
> *Gesendet:* Donnerstag, 4. April 2019 09:13
> *An:* 'users@wicket.apache.org' <users@wicket.apache.org
> <ma...@wicket.apache.org>>
> *Betreff:* Re: Problem with ThreadContext.getSession when session dies
>
>
>
> Hi Sven,
>
>
>
> thanks for the reply.
>
>
>
> The problem is, that at the end of the request in onDetach wicket
> tries to write content of pages into the session (see
> storeTouchedPages in Stack-Trace), which is already dead. To identify
> if wicket needs to store content into session, it checked the
> Session.get() / ThreadContext.getSession() cached Session, which
> represents not the real last state of the session.
>
>
>
> When wicket then writes content into session, it look in the real dead
> session (getSessionStore().getAttribute call).
>
>
>
> So I don’t know the right solution but I could not understand why
> checking state of session is done on a cached version while writing
> than is done on the real one. Does the process not to be consistent
> (check and write in the cached or check and write in the real one)?
>
>
>
> Kind regards
>
>
>
>
>
> *PATRICK SCHWARZER*
> SOFTWARE ENGINEER
>
> *o***+49 89 32175 655
>
> *TOMTEC Imaging Systems GmbH*
> Edisonstrasse 6, 85716 Unterschleissheim, Germany, Managing Director:
> Johannes Waldinger, Dr. Thomas Piehler, HRB 235646 Amtsgericht Muenchen
>
> *imap://francois%2Epapon%40openobject%2Efr@imap.1und1.de:993/fetch%3EUID%3E/INBOX/apache/shiro%3E824?header=quotebody&part=1.2&filename=image003.jpg*
> <http://www.tomtec.de/>
>
>
>
>
>
>
>
> Hi Patrick,
>
>
>
> Wicket uses a temporary session if there's no container session, e.g.
>
> the latter has already expired.
>
> It's not clear to me why that's a problem for you.
>
>
>
> Best regards
>
> Sven
>
>
>
> *Von:*Patrick Schwarzer
> *Gesendet:* Mittwoch, 3. April 2019 13:27
> *An:* 'users@wicket.apache.org' <users@wicket.apache.org
> <ma...@wicket.apache.org>>
> *Betreff:* Problem with ThreadContext.getSession when session dies
>
>
>
> Dear Sir or Madam,
>
> we identified an issue during request handling in Wicket 7.12.0 when
> session dies during processing.
>
> The problem is, that parts of the code accessing current session by
> calling Session.get() which then return a valid session cached in
> ThreadContext.getSession().
>
> imap://francois%2Epapon%40openobject%2Efr@imap.1und1.de:993/fetch%3EUID%3E/INBOX/apache/shiro%3E824?header=quotebody&part=1.3&filename=image004.png
>
> But when accessing an attribute of the Session, the code accesses the
> real session, which is dead and leads to an Exception.
>
> imap://francois%2Epapon%40openobject%2Efr@imap.1und1.de:993/fetch%3EUID%3E/INBOX/apache/shiro%3E824?header=quotebody&part=1.4&filename=image005.png
>
> So we were a little confused why Session.get() and Session.exists()
> return valid results when Session is already dead.
> How we can avoid Session.get() and Session.exists() return valid
> results? Alternatively how we can ensure, that Request with cached
> Session is handled correctly?
>
>
>
>
>
> The stack trace of our problem:
>
> java.lang.IllegalStateException:
> org.apache.shiro.session.UnknownSessionException: There is no session
> with id [48cf6f39-9bf6-4b76-84cd-a106e707af63]
>
> at
> org.apache.shiro.web.servlet.ShiroHttpSession.getAttribute(ShiroHttpSession.java:133)
> ~[shiro-web-1.3.2.jar:1.3.2]
>
> getAttribute:286, HttpSessionStore (org.apache.wicket.session)
>
> getAttribute:743, Session (org.apache.wicket) *<< Why this is not
> accessing cached Session?*
>
> getSessionAttribute:66, DefaultPageManagerContext (org.apache.wicket.page)
>
> getSessionAttribute:101, RequestAdapter (org.apache.wicket.page)
>
> getSessionEntry:414, PageStoreManager$PersistentRequestAdapter
> (org.apache.wicket.page)
>
> storeTouchedPages:438, PageStoreManager$PersistentRequestAdapter
> (org.apache.wicket.page) *<< Should this happen, when Session is
> already dead?*
>
> commitRequest:193, RequestAdapter (org.apache.wicket.page)
>
> commitRequest:76, AbstractPageManager (org.apache.wicket.page)
>
> commitRequest:74, PageManagerDecorator (org.apache.wicket.page)
>
> commitRequest:270, PageAccessSynchronizer$2 (org.apache.wicket.page)
>
> onDetach:1798, Application$3 (org.apache.wicket)
>
> notify:105, RequestCycleListenerCollection$3
> (org.apache.wicket.request.cycle)
>
> notify:101, RequestCycleListenerCollection$3
> (org.apache.wicket.request.cycle)
>
> notify:120, ListenerCollection$1 (org.apache.wicket.util.listener)
>
> reversedNotify:144, ListenerCollection (org.apache.wicket.util.listener)
>
> reversedNotifyIgnoringExceptions:113, ListenerCollection
> (org.apache.wicket.util.listener)
>
> onDetach:100, RequestCycleListenerCollection
> (org.apache.wicket.request.cycle)
>
> onDetach:649, RequestCycle (org.apache.wicket.request.cycle)
>
> detach:594, RequestCycle (org.apache.wicket.request.cycle)
>
> processRequestAndDetach:297, RequestCycle
> (org.apache.wicket.request.cycle)
>
> processRequestCycle:261, WicketFilter (org.apache.wicket.protocol.http)
>
> processRequest:203, WicketFilter (org.apache.wicket.protocol.http)
>
> doFilter:284, WicketFilter (org.apache.wicket.protocol.http)
>
> internalDoFilter:193, ApplicationFilterChain (org.apache.catalina.core)
>
> doFilter:166, ApplicationFilterChain (org.apache.catalina.core)
>
> doFilterInternal:99, RequestContextFilter (org.springframework.web.filter)
>
> doFilter:107, OncePerRequestFilter (org.springframework.web.filter)
>
> internalDoFilter:193, ApplicationFilterChain (org.apache.catalina.core)
>
> doFilter:166, ApplicationFilterChain (org.apache.catalina.core)
>
> doFilter:61, ProxiedFilterChain (org.apache.shiro.web.servlet)
>
> executeChain:108, AdviceFilter (org.apache.shiro.web.servlet)
>
> doFilterInternal:137, AdviceFilter (org.apache.shiro.web.servlet)
>
> doFilter:125, OncePerRequestFilter (org.apache.shiro.web.servlet)
>
> doFilter:66, ProxiedFilterChain (org.apache.shiro.web.servlet)
>
> executeChain:108, AdviceFilter (org.apache.shiro.web.servlet)
>
> doFilterInternal:137, AdviceFilter (org.apache.shiro.web.servlet)
>
> doFilter:125, OncePerRequestFilter (org.apache.shiro.web.servlet)
>
> doFilter:66, ProxiedFilterChain (org.apache.shiro.web.servlet)
>
> executeChain:449, AbstractShiroFilter (org.apache.shiro.web.servlet)
>
> call:365, AbstractShiroFilter$1 (org.apache.shiro.web.servlet)
>
> doCall:90, SubjectCallable (org.apache.shiro.subject.support)
>
> call:83, SubjectCallable (org.apache.shiro.subject.support)
>
> execute:383, DelegatingSubject (org.apache.shiro.subject.support)
>
> doFilterInternal:362, AbstractShiroFilter (org.apache.shiro.web.servlet)
>
> doFilter:125, OncePerRequestFilter (org.apache.shiro.web.servlet)
>
> invokeDelegate:357, DelegatingFilterProxy (org.springframework.web.filter)
>
> doFilter:270, DelegatingFilterProxy (org.springframework.web.filter)
>
> internalDoFilter:193, ApplicationFilterChain (org.apache.catalina.core)
>
> doFilter:166, ApplicationFilterChain (org.apache.catalina.core)
>
> invoke:198, StandardWrapperValve (org.apache.catalina.core)
>
> invoke:96, StandardContextValve (org.apache.catalina.core)
>
> invoke:478, AuthenticatorBase (org.apache.catalina.authenticator)
>
> invoke:140, StandardHostValve (org.apache.catalina.core)
>
> invoke:80, ErrorReportValve (org.apache.catalina.valves)
>
> invoke:650, AbstractAccessLogValve (org.apache.catalina.valves)
>
> invoke:279, RewriteValve (org.apache.catalina.valves.rewrite)
>
> invoke:677, RemoteIpValve (org.apache.catalina.valves)
>
> invoke:87, StandardEngineValve (org.apache.catalina.core)
>
> service:342, CoyoteAdapter (org.apache.catalina.connector)
>
> service:799, Http11Processor (org.apache.coyote.http11)
>
> process:66, AbstractProcessorLight (org.apache.coyote)
>
> process:868, AbstractProtocol$ConnectionHandler (org.apache.coyote)
>
> doRun:1457, NioEndpoint$SocketProcessor (org.apache.tomcat.util.net)
>
> run:49, SocketProcessorBase (org.apache.tomcat.util.net)
>
> runWorker:1149, ThreadPoolExecutor (java.util.concurrent)
>
> run:624, ThreadPoolExecutor$Worker (java.util.concurrent)
>
> run:61, TaskThread$WrappingRunnable (org.apache.tomcat.util.threads)
>
> run:748, Thread (java.lang)
>
> Kind regards
>
>
>
> *PATRICK SCHWARZER*
> SOFTWARE ENGINEER
>
> *o***+49 89 32175 655
>
> *TOMTEC Imaging Systems GmbH*
> Edisonstrasse 6, 85716 Unterschleissheim, Germany, Managing Director:
> Johannes Waldinger, Dr. Thomas Piehler, HRB 235646 Amtsgericht Muenchen
>
> *imap://francois%2Epapon%40openobject%2Efr@imap.1und1.de:993/fetch%3EUID%3E/INBOX/apache/shiro%3E824?header=quotebody&part=1.2&filename=image003.jpg*
> <http://www.tomtec.de/>
>