You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@wicket.apache.org by Bernard <bh...@gmail.com> on 2013/12/08 09:26:18 UTC
Please comment on this Dilemma
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
Re: Please comment on this Dilemma
Posted by Bernard <bh...@gmail.com>.
Hi Martin,
Thanks for your suggestions.
I cannot send the user to a logout page from a page that is re-created
after expiry. That is because I have to first check my assumptions,
and this needs to happen in the page the user interacts with.
The state of the link on the expired page in the browser might not
reflect the state of the user who might have acted in a different
browser window etc..
But I don't want to distract from the real issue which you are raising
- whether a componsnt can cause errors when invoking behaviour after
re-creation of the page.
First I need to clarify that I am not asking for change of the current
default implementation which is to prevent such execution after
expiry.
I am only asking that a specific component, that receives such
behaviour after expiry, can decide whether it wants to execute it, by
overriding Wicket default behaviour.
In such a case, the developer would override a new method in Component
that returns boolean true if it wants to allow execution after expiry.
Could you please elaborate why this would be a problem?
As an example for this discussion, I chose the logout link that has no
other business than doing back-end logic and then optionally send the
user to a different page. Why would Wicket want to prevent me from
doing this?
Furthermore, if the developer could allow on Page level PageParameters
be processed after expiry, then this would help to extend he scope of
such after-expiry execution, because the PageParameters could be used
to restore the state of the page to such an extent that interaction
with it could be improved. I am fully aware that there are risks
associated with this in some cases if the developer does not consider
the consequences. But that could be covered with a couple of sentences
in the API documentation.
Does all this not sound reasonable and doable without having an impact
on Wicket default functionality? The changes would be minimal and
trivial.
Regards,
Bernard
On Tue, 10 Dec 2013 11:13:57 +0200, you wrote:
>Hi,
>
>
>On Tue, Dec 10, 2013 at 10:51 AM, Bernard <bh...@gmail.com> 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 <bh...@gmail.com> 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
>>
>>
---
This email is free from viruses and malware because avast! Antivirus protection is active.
http://www.avast.com
Re: Please comment on this Dilemma
Posted by Martin Grigorov <mg...@apache.org>.
Hi,
On Tue, Dec 10, 2013 at 10:51 AM, Bernard <bh...@gmail.com> 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 <bh...@gmail.com> 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
>
>
Re: Please comment on this Dilemma
Posted by Bernard <bh...@gmail.com>.
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.
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.
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 <bh...@gmail.com> 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
Re: Please comment on this Dilemma
Posted by tetsuo <ro...@gmail.com>.
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 <bh...@gmail.com> 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
>
>
Re: Please comment on this Dilemma
Posted by Bernard <bh...@gmail.com>.
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
Re: Please comment on this Dilemma
Posted by Andrea Del Bene <an...@gmail.com>.
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
>