Hi Andrea, Thanks for your suggestion.
I tried hard to think about a benefit that onInvalidate() could provide. I cannot think of one for this scenario. I cannot negate the fact that the session expires - it must do so. I cannot avoid that the user sits on that page - that is the way it is plus a requirement. What I can see though, and it becomes clearer in my mind the more I think about it, is this: Wicket prevents in a vigorous way via its limiting policies, that a logical request from an authenticated user (via remember-me cookie) reaches its target. ...! >From a technical perspective, in comparison with what is technical achievable with the HTTP protocol, and with much less sophisticated frameworks, this situation appears unacceptable. Wicket simply denies service because of its assumptions. This is surprising, because Wicket has configurations and options for almost anything. I am still thinking that Component should be able to decide autonomously whether it wants to have behaviours invoked after session expiry. Component can decide itself whether the environment is right for invocation. BTW this would short-cut this enormously expensive checking of the whole component hierarchy for stateful components. In other words, when we work on a framework and not on an application, and we are faced with the decision to deny service, or turn something off, then there needs to be an option to override / configure this. Here, we have clearly shot ourselves in the foot. Along the same lines, Wicket has decided to ignore PageParameters when re-constructing an expired page. "Do not use the parsed PageParameters when re-creating an expired page" https://issues.apache.org/jira/browse/WICKET-4594 Again, this is counter-productive in some scenarios. PageParameters can be vital for re-creating the component state which is exactly what we may need to compensate for the loss of state stored in the expired session! Again this should be configurable. I can see a trend towards more client side state. Wicket makes it too hard to go there unless one goes full stateless which is impossible because AJAX makes every page stateful. That is what I call a Dilemma. Regards, Bernard On Sun, 08 Dec 2013 21:13:17 +0100, you wrote: >Since you need to do some actions on session expiration, have you >considered to use method onInvalidate() of Session? >> Hi all, >> >> Please consider the following scenario: >> >> The user clicks a logout link after the session is expired. The link >> needs to execute behaviour on the server while the page it is on has >> no relevance - it may not even be rendered. While the page has >> expired, the user has a fresh authenticated session thanks to >> remember-me cookie. This situation is frustrating because the user >> will NOT understand that anything can expire with a remember-me >> cookie. The logout action is required to destroy the remember-me >> cookie. >> >> We require that the behaviour of a logout be invoked under all >> conditions even if the page is stateful e.g. if there are AJAX >> components on the page. >> >> We are in a better position now after the fix of >> >> Mounted bookmarkable Page not recreated on Session Expiry >> https://issues.apache.org/jira/browse/WICKET-4997 >> >> However while the page is found after expiry, the link behaviour is >> not executed. >> >> Wicket does not do this in order to prevent unexpected results in case >> of invalid component state. See >> >> Do not use the parsed PageParameters when re-creating an expired page >> https://issues.apache.org/jira/browse/WICKET-4594 >> >> and >> >> Page#isPageStateless() may return wrong value >> https://issues.apache.org/jira/browse/WICKET-5083 >> >> Because of the policies behind these issues, on application level it >> appears futile trying to apply tricks like adding stateful components >> in onBeforeRender(). >> >> This would allow ListenerInterfaceRequestHandler#respond() to >> consider a page stateless in the early construction phase. I have been >> able to use this technique, but it is against these policies, ugly, >> and I have some doubts whether it still works. >> >> >> So how can this requirement be met? I can imagine that Wicket could >> let each component override Wicket's behaviour blocking, but there >> might be better solutions. >> >> Regards, >> >> Bernard >> >> >> --- >> This email is free from viruses and malware because avast! Antivirus >> protection is active. >> http://www.avast.com >> --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com
