Couldn't the logout link be stateless (or point to a stateless bookmarkable page, or point to a resource), thus avoiding the need for recreating the stateful expired page?
On Mon, Dec 9, 2013 at 4:09 AM, Bernard <[email protected]> wrote: > 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 > >
