Hi,
On Tue, Dec 10, 2013 at 10:51 AM, Bernard <[email protected]> wrote: > Hi Ronald, > > Thanks for your ideas, much appreciated. > > The signout link at a minimum has to manage the remember-me cookie > authentication and a single signon solution. It is a StatelessLink so > in principle it dose not need any state to function. But a simple > static link as you suggest will not do it. > Why a BookmarkablePageLink pointing to LogoutPage (a stateless page) won't be able to do the same ? Clicking on this link will at *any* time, no matter whether the http session has expired or not will lead to the LogoutPage. There you can check whether there is an authenticated user in the current session and clean whatever is needed. Since the user clicks on the logout link then he wants to delete the remember me cookie, so you can set maxAge to -1 in all cases. Make sure your IAuthenticationStrategy allows access for anonymous users to LogoutPage. > > My example is simplified to make the case clearer. > > I have a large spreadsheet of pages to track their expire behaviour. > For most of them, there is some kind of trivial state involved like > AJAX toggle buttons that would need page creation anyway. > > I have coded workarounds and they are truly awful. I am trying to get > a framework solution which appears to be so much easier. > See https://issues.apache.org/jira/browse/WICKET-5421 It is not easy to explain to the application developer that ComponentNotFoundException is a problem in the application, 99% of the cases. Maybe there is a bug in Wicket for the rest 1%. If you think it is easy then please subscribe to JIRA notifications and help us dealing with such tickets. A component cannot say whether it may be used or not after an automatic page re-creation because of the same reason - the component may not be there. > > Regards, > > Bernard > > > On Mon, 9 Dec 2013 09:56:38 -0200, you wrote: > > >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 > >> > >> > > > --- > This email is free from viruses and malware because avast! Antivirus > protection is active. > http://www.avast.com > >
