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 [email protected] 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:[email protected]* <http://www.tomtec.de/> > > Hi Patrick, > > > > On Thu, Apr 4, 2019 at 10:16 AM Patrick Schwarzer < > > [email protected] <mailto:[email protected]>> 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:* '[email protected]' <[email protected] > <mailto:[email protected]>> > *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%[email protected]: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:* '[email protected]' <[email protected] > <mailto:[email protected]>> > *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%[email protected]: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%[email protected]: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%[email protected]:993/fetch%3EUID%3E/INBOX/apache/shiro%3E824?header=quotebody&part=1.2&filename=image003.jpg* > <http://www.tomtec.de/> >
