Re: Logout (Session destroy) on the last (stateful) page?
If that bookmarkable uri is a stateless page, will that prevent a new
session from being established? (Assuming the default session store is in
use)
On Dec 3, 2010 10:14 PM, "Igor Vaynberg" wrote:
> it is a good idea to always redirect to a bookmarkable url after
> invalidating your session.
>
> -igor
>
> On Thu, Dec 2, 2010 at 2:08 AM, Ernesto Reinaldo Barreiro
> wrote:
>> e.g. you could:
>>
>> 1-Place and AbstractDefaultAjaxBehavior on you page (e.g. to some div
>> on your page). Use urlFor to generate the URL to this behavior. On
>>
>> respond(AjaxRequestTarget target) {
>>Invalidate your session.
>> }
>>
>> 2-Make your page implement IHeaderContributor and on
>>
>> public void renderHead(IHeaderResponse response) {
>>response.renderOnDomReadyJavascript("here use jquery AJAX
to call
>> URL of step 1");
>> }
>>
>> Ernesto
>>
>> On Thu, Dec 2, 2010 at 10:54 AM, Ernesto Reinaldo Barreiro
>> wrote:
>>> Hi Matt,
>>>
>>> I see. Then maybe adding some "onDomReady" javascript to
>>> ConfirmationPage that simply goes back to the server and invalidates
>>> the session? Probably this can't use wicket AJAX machinery: because
>>> that will probably will also trigger a redirect.
>>>
>>> Regards,
>>>
>>> Ernesto
>>>
>>> On Thu, Dec 2, 2010 at 10:46 AM, Matthias Keller
>>> wrote:
Hi Ernesto
No that's not possible because the ConfirmationPage is *stateful* and
contains lots of information from the session/page state, so it must be
allowed to display the pre-rendered page once but after that request,
the
session must be invalidated.
Thanks
Matt
On 2010-12-02 10:34, Ernesto Reinaldo Barreiro wrote:
>
> Matt,
>
> Can't you just do some kind of trick so that your ConfirmationPage is
> served as the home page? So that you invalidate the session but at
> getHomePage() you temporarily return your ConfirmationPage?
>
> Regards,
>
> Ernesto
>
> On Thu, Dec 2, 2010 at 10:06 AM, Matthias Keller
> wrote:
>>
>> Hi Randy
>>
>> Yes it appears to have something to do with that. Our app uses the
>> REDIRECT_BUFFER by default (we never actively configured this though)
>> which
>> appears to be a sensible option for normal operation. I'm not very
>> familiar
>> with the render strategies but you appear to be right: The page is
>> actually
>> rendered at the end of the previous request where the session is
>> invalidated
>> too. Then a redirect happens to the pre-rendered page which fails
because
>> the Session is already gone...
>>
>> Is there any hook that will be called at the end of the second
request
>> serving the pre-rendered content?
>> I found a workaround for the moment: In the previous page, I
explicitly
>> set
>> setRedirect(false); but this has the consequence that if the user
hits
>> reload on the confirmation page, he will first be asked about
resending
>> the
>> POST parameters...
>>
>> Anything we could do to invalidate the session at the end of the
serving
>> of
>> the prerendered page?
>>
>> Thanks a lot
>>
>> Matt
>>
>> On 2010-12-01 20:44, Randy S. wrote:
>>>
>>> Does the redirect to the home page happen because of Wicket's
default
>>> render
>>> strategy (REDIRECT_TO_BUFFER) that causes two requests? You
invalidate
>>> session on the first which redirects to the buffered response. When
the
>>> second request comes in expecting to get the already-rendered
response,
>>> you
>>> get a new session.
>>>
>>>
>>> On Wed, Dec 1, 2010 at 11:53 AM, Martin Makundi<
>>> martin.maku...@koodaripalvelut.com>wrote:
>>>
Hi!
I am curious too. For this reason we had to build our logoutpage so
that it invalidtes session logically but not in httpsession sense.
Only clicking something from login page will do that.
But it's a hack, I would like to know what's the proper way ;)
**
Martin
2010/12/1 Matthias Keller:
>
> Hi
>
> I've got the following problem:
> After a user completes a wizard, he sees a last confirmation page
containing
>
> some data, thus it must be a stateful page called by the following
> code
from
>
> the wizard:
>>
>> setResponsePage(new ConfirmationPage(myBean));
>
> This ConfirmationPage must only be displayed once, thus if the
user
> does
a
>
> refresh it must not be available anymore.
> I expected that I would be able to call session.invalidate() from
somewhere
>
> within the ConfirmationPage's onAfterRender or onDetach methods.
>>
Re: Logout (Session destroy) on the last (stateful) page?
maybe i misunderstood, but wouldn't removing the page from the page map be sufficient? we do this for our confirmation pages that show sensitive data (like temporary passwords). -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Logout-Session-destroy-on-the-last-stateful-page-tp3067753p3072309.html Sent from the Users forum mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Logout (Session destroy) on the last (stateful) page?
Isn't this what will happen next time he tried to "visit" any page on
the server?
Ernesto
On Sat, Dec 4, 2010 at 5:13 AM, Igor Vaynberg wrote:
> it is a good idea to always redirect to a bookmarkable url after
> invalidating your session.
>
> -igor
>
> On Thu, Dec 2, 2010 at 2:08 AM, Ernesto Reinaldo Barreiro
> wrote:
>> e.g. you could:
>>
>> 1-Place and AbstractDefaultAjaxBehavior on you page (e.g. to some div
>> on your page). Use urlFor to generate the URL to this behavior. On
>>
>> respond(AjaxRequestTarget target) {
>> Invalidate your session.
>> }
>>
>> 2-Make your page implement IHeaderContributor and on
>>
>> public void renderHead(IHeaderResponse response) {
>> response.renderOnDomReadyJavascript("here use jquery AJAX to
>> call
>> URL of step 1");
>> }
>>
>> Ernesto
>>
>> On Thu, Dec 2, 2010 at 10:54 AM, Ernesto Reinaldo Barreiro
>> wrote:
>>> Hi Matt,
>>>
>>> I see. Then maybe adding some "onDomReady" javascript to
>>> ConfirmationPage that simply goes back to the server and invalidates
>>> the session? Probably this can't use wicket AJAX machinery: because
>>> that will probably will also trigger a redirect.
>>>
>>> Regards,
>>>
>>> Ernesto
>>>
>>> On Thu, Dec 2, 2010 at 10:46 AM, Matthias Keller
>>> wrote:
Hi Ernesto
No that's not possible because the ConfirmationPage is *stateful* and
contains lots of information from the session/page state, so it must be
allowed to display the pre-rendered page once but after that request, the
session must be invalidated.
Thanks
Matt
On 2010-12-02 10:34, Ernesto Reinaldo Barreiro wrote:
>
> Matt,
>
> Can't you just do some kind of trick so that your ConfirmationPage is
> served as the home page? So that you invalidate the session but at
> getHomePage() you temporarily return your ConfirmationPage?
>
> Regards,
>
> Ernesto
>
> On Thu, Dec 2, 2010 at 10:06 AM, Matthias Keller
> wrote:
>>
>> Hi Randy
>>
>> Yes it appears to have something to do with that. Our app uses the
>> REDIRECT_BUFFER by default (we never actively configured this though)
>> which
>> appears to be a sensible option for normal operation. I'm not very
>> familiar
>> with the render strategies but you appear to be right: The page is
>> actually
>> rendered at the end of the previous request where the session is
>> invalidated
>> too. Then a redirect happens to the pre-rendered page which fails because
>> the Session is already gone...
>>
>> Is there any hook that will be called at the end of the second request
>> serving the pre-rendered content?
>> I found a workaround for the moment: In the previous page, I explicitly
>> set
>> setRedirect(false); but this has the consequence that if the user hits
>> reload on the confirmation page, he will first be asked about resending
>> the
>> POST parameters...
>>
>> Anything we could do to invalidate the session at the end of the serving
>> of
>> the prerendered page?
>>
>> Thanks a lot
>>
>> Matt
>>
>> On 2010-12-01 20:44, Randy S. wrote:
>>>
>>> Does the redirect to the home page happen because of Wicket's default
>>> render
>>> strategy (REDIRECT_TO_BUFFER) that causes two requests? You invalidate
>>> session on the first which redirects to the buffered response. When the
>>> second request comes in expecting to get the already-rendered response,
>>> you
>>> get a new session.
>>>
>>>
>>> On Wed, Dec 1, 2010 at 11:53 AM, Martin Makundi<
>>> martin.maku...@koodaripalvelut.com> wrote:
>>>
Hi!
I am curious too. For this reason we had to build our logoutpage so
that it invalidtes session logically but not in httpsession sense.
Only clicking something from login page will do that.
But it's a hack, I would like to know what's the proper way ;)
**
Martin
2010/12/1 Matthias Keller:
>
> Hi
>
> I've got the following problem:
> After a user completes a wizard, he sees a last confirmation page
containing
>
> some data, thus it must be a stateful page called by the following
> code
from
>
> the wizard:
>>
>> setResponsePage(new ConfirmationPage(myBean));
>
> This ConfirmationPage must only be displayed once, thus if the user
> does
a
>
> refresh it must not be available anymore.
> I expected that I would be able to call session.invalidate() from
somewhere
>
> within the ConfirmationPage's onAfterRender or onDetach methods.
> Unfortunately, whenever I do this, the user
Re: Logout (Session destroy) on the last (stateful) page?
it is a good idea to always redirect to a bookmarkable url after
invalidating your session.
-igor
On Thu, Dec 2, 2010 at 2:08 AM, Ernesto Reinaldo Barreiro
wrote:
> e.g. you could:
>
> 1-Place and AbstractDefaultAjaxBehavior on you page (e.g. to some div
> on your page). Use urlFor to generate the URL to this behavior. On
>
> respond(AjaxRequestTarget target) {
> Invalidate your session.
> }
>
> 2-Make your page implement IHeaderContributor and on
>
> public void renderHead(IHeaderResponse response) {
> response.renderOnDomReadyJavascript("here use jquery AJAX to
> call
> URL of step 1");
> }
>
> Ernesto
>
> On Thu, Dec 2, 2010 at 10:54 AM, Ernesto Reinaldo Barreiro
> wrote:
>> Hi Matt,
>>
>> I see. Then maybe adding some "onDomReady" javascript to
>> ConfirmationPage that simply goes back to the server and invalidates
>> the session? Probably this can't use wicket AJAX machinery: because
>> that will probably will also trigger a redirect.
>>
>> Regards,
>>
>> Ernesto
>>
>> On Thu, Dec 2, 2010 at 10:46 AM, Matthias Keller
>> wrote:
>>> Hi Ernesto
>>>
>>> No that's not possible because the ConfirmationPage is *stateful* and
>>> contains lots of information from the session/page state, so it must be
>>> allowed to display the pre-rendered page once but after that request, the
>>> session must be invalidated.
>>>
>>> Thanks
>>>
>>> Matt
>>>
>>> On 2010-12-02 10:34, Ernesto Reinaldo Barreiro wrote:
Matt,
Can't you just do some kind of trick so that your ConfirmationPage is
served as the home page? So that you invalidate the session but at
getHomePage() you temporarily return your ConfirmationPage?
Regards,
Ernesto
On Thu, Dec 2, 2010 at 10:06 AM, Matthias Keller
wrote:
>
> Hi Randy
>
> Yes it appears to have something to do with that. Our app uses the
> REDIRECT_BUFFER by default (we never actively configured this though)
> which
> appears to be a sensible option for normal operation. I'm not very
> familiar
> with the render strategies but you appear to be right: The page is
> actually
> rendered at the end of the previous request where the session is
> invalidated
> too. Then a redirect happens to the pre-rendered page which fails because
> the Session is already gone...
>
> Is there any hook that will be called at the end of the second request
> serving the pre-rendered content?
> I found a workaround for the moment: In the previous page, I explicitly
> set
> setRedirect(false); but this has the consequence that if the user hits
> reload on the confirmation page, he will first be asked about resending
> the
> POST parameters...
>
> Anything we could do to invalidate the session at the end of the serving
> of
> the prerendered page?
>
> Thanks a lot
>
> Matt
>
> On 2010-12-01 20:44, Randy S. wrote:
>>
>> Does the redirect to the home page happen because of Wicket's default
>> render
>> strategy (REDIRECT_TO_BUFFER) that causes two requests? You invalidate
>> session on the first which redirects to the buffered response. When the
>> second request comes in expecting to get the already-rendered response,
>> you
>> get a new session.
>>
>>
>> On Wed, Dec 1, 2010 at 11:53 AM, Martin Makundi<
>> martin.maku...@koodaripalvelut.com> wrote:
>>
>>> Hi!
>>>
>>> I am curious too. For this reason we had to build our logoutpage so
>>> that it invalidtes session logically but not in httpsession sense.
>>>
>>> Only clicking something from login page will do that.
>>>
>>> But it's a hack, I would like to know what's the proper way ;)
>>>
>>> **
>>> Martin
>>>
>>>
>>>
>>> 2010/12/1 Matthias Keller:
Hi
I've got the following problem:
After a user completes a wizard, he sees a last confirmation page
>>>
>>> containing
some data, thus it must be a stateful page called by the following
code
>>>
>>> from
the wizard:
>
> setResponsePage(new ConfirmationPage(myBean));
This ConfirmationPage must only be displayed once, thus if the user
does
>>>
>>> a
refresh it must not be available anymore.
I expected that I would be able to call session.invalidate() from
>>>
>>> somewhere
within the ConfirmationPage's onAfterRender or onDetach methods.
Unfortunately, whenever I do this, the user is automatically
redirected
>>>
>>> to
the home page without a trace in the logs
Any idea how to do that?
Thanks
Matt
>>>
>>>
>>>
>>
>
>
Re: Logout (Session destroy) on the last (stateful) page?
e.g. you could:
1-Place and AbstractDefaultAjaxBehavior on you page (e.g. to some div
on your page). Use urlFor to generate the URL to this behavior. On
respond(AjaxRequestTarget target) {
Invalidate your session.
}
2-Make your page implement IHeaderContributor and on
public void renderHead(IHeaderResponse response) {
response.renderOnDomReadyJavascript("here use jquery AJAX to
call
URL of step 1");
}
Ernesto
On Thu, Dec 2, 2010 at 10:54 AM, Ernesto Reinaldo Barreiro
wrote:
> Hi Matt,
>
> I see. Then maybe adding some "onDomReady" javascript to
> ConfirmationPage that simply goes back to the server and invalidates
> the session? Probably this can't use wicket AJAX machinery: because
> that will probably will also trigger a redirect.
>
> Regards,
>
> Ernesto
>
> On Thu, Dec 2, 2010 at 10:46 AM, Matthias Keller
> wrote:
>> Hi Ernesto
>>
>> No that's not possible because the ConfirmationPage is *stateful* and
>> contains lots of information from the session/page state, so it must be
>> allowed to display the pre-rendered page once but after that request, the
>> session must be invalidated.
>>
>> Thanks
>>
>> Matt
>>
>> On 2010-12-02 10:34, Ernesto Reinaldo Barreiro wrote:
>>>
>>> Matt,
>>>
>>> Can't you just do some kind of trick so that your ConfirmationPage is
>>> served as the home page? So that you invalidate the session but at
>>> getHomePage() you temporarily return your ConfirmationPage?
>>>
>>> Regards,
>>>
>>> Ernesto
>>>
>>> On Thu, Dec 2, 2010 at 10:06 AM, Matthias Keller
>>> wrote:
Hi Randy
Yes it appears to have something to do with that. Our app uses the
REDIRECT_BUFFER by default (we never actively configured this though)
which
appears to be a sensible option for normal operation. I'm not very
familiar
with the render strategies but you appear to be right: The page is
actually
rendered at the end of the previous request where the session is
invalidated
too. Then a redirect happens to the pre-rendered page which fails because
the Session is already gone...
Is there any hook that will be called at the end of the second request
serving the pre-rendered content?
I found a workaround for the moment: In the previous page, I explicitly
set
setRedirect(false); but this has the consequence that if the user hits
reload on the confirmation page, he will first be asked about resending
the
POST parameters...
Anything we could do to invalidate the session at the end of the serving
of
the prerendered page?
Thanks a lot
Matt
On 2010-12-01 20:44, Randy S. wrote:
>
> Does the redirect to the home page happen because of Wicket's default
> render
> strategy (REDIRECT_TO_BUFFER) that causes two requests? You invalidate
> session on the first which redirects to the buffered response. When the
> second request comes in expecting to get the already-rendered response,
> you
> get a new session.
>
>
> On Wed, Dec 1, 2010 at 11:53 AM, Martin Makundi<
> martin.maku...@koodaripalvelut.com> wrote:
>
>> Hi!
>>
>> I am curious too. For this reason we had to build our logoutpage so
>> that it invalidtes session logically but not in httpsession sense.
>>
>> Only clicking something from login page will do that.
>>
>> But it's a hack, I would like to know what's the proper way ;)
>>
>> **
>> Martin
>>
>>
>>
>> 2010/12/1 Matthias Keller:
>>>
>>> Hi
>>>
>>> I've got the following problem:
>>> After a user completes a wizard, he sees a last confirmation page
>>
>> containing
>>>
>>> some data, thus it must be a stateful page called by the following
>>> code
>>
>> from
>>>
>>> the wizard:
setResponsePage(new ConfirmationPage(myBean));
>>>
>>> This ConfirmationPage must only be displayed once, thus if the user
>>> does
>>
>> a
>>>
>>> refresh it must not be available anymore.
>>> I expected that I would be able to call session.invalidate() from
>>
>> somewhere
>>>
>>> within the ConfirmationPage's onAfterRender or onDetach methods.
>>> Unfortunately, whenever I do this, the user is automatically
>>> redirected
>>
>> to
>>>
>>> the home page without a trace in the logs
>>> Any idea how to do that?
>>>
>>> Thanks
>>>
>>> Matt
>>>
>>>
>>
>>
>>
>
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: Logout (Session destroy) on the last (stateful) page?
Hi Matt, I see. Then maybe adding some "onDomReady" javascript to ConfirmationPage that simply goes back to the server and invalidates the session? Probably this can't use wicket AJAX machinery: because that will probably will also trigger a redirect. Regards, Ernesto On Thu, Dec 2, 2010 at 10:46 AM, Matthias Keller wrote: > Hi Ernesto > > No that's not possible because the ConfirmationPage is *stateful* and > contains lots of information from the session/page state, so it must be > allowed to display the pre-rendered page once but after that request, the > session must be invalidated. > > Thanks > > Matt > > On 2010-12-02 10:34, Ernesto Reinaldo Barreiro wrote: >> >> Matt, >> >> Can't you just do some kind of trick so that your ConfirmationPage is >> served as the home page? So that you invalidate the session but at >> getHomePage() you temporarily return your ConfirmationPage? >> >> Regards, >> >> Ernesto >> >> On Thu, Dec 2, 2010 at 10:06 AM, Matthias Keller >> wrote: >>> >>> Hi Randy >>> >>> Yes it appears to have something to do with that. Our app uses the >>> REDIRECT_BUFFER by default (we never actively configured this though) >>> which >>> appears to be a sensible option for normal operation. I'm not very >>> familiar >>> with the render strategies but you appear to be right: The page is >>> actually >>> rendered at the end of the previous request where the session is >>> invalidated >>> too. Then a redirect happens to the pre-rendered page which fails because >>> the Session is already gone... >>> >>> Is there any hook that will be called at the end of the second request >>> serving the pre-rendered content? >>> I found a workaround for the moment: In the previous page, I explicitly >>> set >>> setRedirect(false); but this has the consequence that if the user hits >>> reload on the confirmation page, he will first be asked about resending >>> the >>> POST parameters... >>> >>> Anything we could do to invalidate the session at the end of the serving >>> of >>> the prerendered page? >>> >>> Thanks a lot >>> >>> Matt >>> >>> On 2010-12-01 20:44, Randy S. wrote: Does the redirect to the home page happen because of Wicket's default render strategy (REDIRECT_TO_BUFFER) that causes two requests? You invalidate session on the first which redirects to the buffered response. When the second request comes in expecting to get the already-rendered response, you get a new session. On Wed, Dec 1, 2010 at 11:53 AM, Martin Makundi< martin.maku...@koodaripalvelut.com> wrote: > Hi! > > I am curious too. For this reason we had to build our logoutpage so > that it invalidtes session logically but not in httpsession sense. > > Only clicking something from login page will do that. > > But it's a hack, I would like to know what's the proper way ;) > > ** > Martin > > > > 2010/12/1 Matthias Keller: >> >> Hi >> >> I've got the following problem: >> After a user completes a wizard, he sees a last confirmation page > > containing >> >> some data, thus it must be a stateful page called by the following >> code > > from >> >> the wizard: >>> >>> setResponsePage(new ConfirmationPage(myBean)); >> >> This ConfirmationPage must only be displayed once, thus if the user >> does > > a >> >> refresh it must not be available anymore. >> I expected that I would be able to call session.invalidate() from > > somewhere >> >> within the ConfirmationPage's onAfterRender or onDetach methods. >> Unfortunately, whenever I do this, the user is automatically >> redirected > > to >> >> the home page without a trace in the logs >> Any idea how to do that? >> >> Thanks >> >> Matt >> >> > > > - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Logout (Session destroy) on the last (stateful) page?
Hi Ernesto No that's not possible because the ConfirmationPage is *stateful* and contains lots of information from the session/page state, so it must be allowed to display the pre-rendered page once but after that request, the session must be invalidated. Thanks Matt On 2010-12-02 10:34, Ernesto Reinaldo Barreiro wrote: Matt, Can't you just do some kind of trick so that your ConfirmationPage is served as the home page? So that you invalidate the session but at getHomePage() you temporarily return your ConfirmationPage? Regards, Ernesto On Thu, Dec 2, 2010 at 10:06 AM, Matthias Keller wrote: Hi Randy Yes it appears to have something to do with that. Our app uses the REDIRECT_BUFFER by default (we never actively configured this though) which appears to be a sensible option for normal operation. I'm not very familiar with the render strategies but you appear to be right: The page is actually rendered at the end of the previous request where the session is invalidated too. Then a redirect happens to the pre-rendered page which fails because the Session is already gone... Is there any hook that will be called at the end of the second request serving the pre-rendered content? I found a workaround for the moment: In the previous page, I explicitly set setRedirect(false); but this has the consequence that if the user hits reload on the confirmation page, he will first be asked about resending the POST parameters... Anything we could do to invalidate the session at the end of the serving of the prerendered page? Thanks a lot Matt On 2010-12-01 20:44, Randy S. wrote: Does the redirect to the home page happen because of Wicket's default render strategy (REDIRECT_TO_BUFFER) that causes two requests? You invalidate session on the first which redirects to the buffered response. When the second request comes in expecting to get the already-rendered response, you get a new session. On Wed, Dec 1, 2010 at 11:53 AM, Martin Makundi< martin.maku...@koodaripalvelut.com>wrote: Hi! I am curious too. For this reason we had to build our logoutpage so that it invalidtes session logically but not in httpsession sense. Only clicking something from login page will do that. But it's a hack, I would like to know what's the proper way ;) ** Martin 2010/12/1 Matthias Keller: Hi I've got the following problem: After a user completes a wizard, he sees a last confirmation page containing some data, thus it must be a stateful page called by the following code from the wizard: setResponsePage(new ConfirmationPage(myBean)); This ConfirmationPage must only be displayed once, thus if the user does a refresh it must not be available anymore. I expected that I would be able to call session.invalidate() from somewhere within the ConfirmationPage's onAfterRender or onDetach methods. Unfortunately, whenever I do this, the user is automatically redirected to the home page without a trace in the logs Any idea how to do that? Thanks Matt smime.p7s Description: S/MIME Cryptographic Signature
Re: Logout (Session destroy) on the last (stateful) page?
Matt, Can't you just do some kind of trick so that your ConfirmationPage is served as the home page? So that you invalidate the session but at getHomePage() you temporarily return your ConfirmationPage? Regards, Ernesto On Thu, Dec 2, 2010 at 10:06 AM, Matthias Keller wrote: > Hi Randy > > Yes it appears to have something to do with that. Our app uses the > REDIRECT_BUFFER by default (we never actively configured this though) which > appears to be a sensible option for normal operation. I'm not very familiar > with the render strategies but you appear to be right: The page is actually > rendered at the end of the previous request where the session is invalidated > too. Then a redirect happens to the pre-rendered page which fails because > the Session is already gone... > > Is there any hook that will be called at the end of the second request > serving the pre-rendered content? > I found a workaround for the moment: In the previous page, I explicitly set > setRedirect(false); but this has the consequence that if the user hits > reload on the confirmation page, he will first be asked about resending the > POST parameters... > > Anything we could do to invalidate the session at the end of the serving of > the prerendered page? > > Thanks a lot > > Matt > > On 2010-12-01 20:44, Randy S. wrote: >> >> Does the redirect to the home page happen because of Wicket's default >> render >> strategy (REDIRECT_TO_BUFFER) that causes two requests? You invalidate >> session on the first which redirects to the buffered response. When the >> second request comes in expecting to get the already-rendered response, >> you >> get a new session. >> >> >> On Wed, Dec 1, 2010 at 11:53 AM, Martin Makundi< >> martin.maku...@koodaripalvelut.com> wrote: >> >>> Hi! >>> >>> I am curious too. For this reason we had to build our logoutpage so >>> that it invalidtes session logically but not in httpsession sense. >>> >>> Only clicking something from login page will do that. >>> >>> But it's a hack, I would like to know what's the proper way ;) >>> >>> ** >>> Martin >>> >>> >>> >>> 2010/12/1 Matthias Keller: Hi I've got the following problem: After a user completes a wizard, he sees a last confirmation page >>> >>> containing some data, thus it must be a stateful page called by the following code >>> >>> from the wizard: > > setResponsePage(new ConfirmationPage(myBean)); This ConfirmationPage must only be displayed once, thus if the user does >>> >>> a refresh it must not be available anymore. I expected that I would be able to call session.invalidate() from >>> >>> somewhere within the ConfirmationPage's onAfterRender or onDetach methods. Unfortunately, whenever I do this, the user is automatically redirected >>> >>> to the home page without a trace in the logs Any idea how to do that? Thanks Matt > > > - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Logout (Session destroy) on the last (stateful) page?
Hi Randy Yes it appears to have something to do with that. Our app uses the REDIRECT_BUFFER by default (we never actively configured this though) which appears to be a sensible option for normal operation. I'm not very familiar with the render strategies but you appear to be right: The page is actually rendered at the end of the previous request where the session is invalidated too. Then a redirect happens to the pre-rendered page which fails because the Session is already gone... Is there any hook that will be called at the end of the second request serving the pre-rendered content? I found a workaround for the moment: In the previous page, I explicitly set setRedirect(false); but this has the consequence that if the user hits reload on the confirmation page, he will first be asked about resending the POST parameters... Anything we could do to invalidate the session at the end of the serving of the prerendered page? Thanks a lot Matt On 2010-12-01 20:44, Randy S. wrote: Does the redirect to the home page happen because of Wicket's default render strategy (REDIRECT_TO_BUFFER) that causes two requests? You invalidate session on the first which redirects to the buffered response. When the second request comes in expecting to get the already-rendered response, you get a new session. On Wed, Dec 1, 2010 at 11:53 AM, Martin Makundi< martin.maku...@koodaripalvelut.com> wrote: Hi! I am curious too. For this reason we had to build our logoutpage so that it invalidtes session logically but not in httpsession sense. Only clicking something from login page will do that. But it's a hack, I would like to know what's the proper way ;) ** Martin 2010/12/1 Matthias Keller: Hi I've got the following problem: After a user completes a wizard, he sees a last confirmation page containing some data, thus it must be a stateful page called by the following code from the wizard: setResponsePage(new ConfirmationPage(myBean)); This ConfirmationPage must only be displayed once, thus if the user does a refresh it must not be available anymore. I expected that I would be able to call session.invalidate() from somewhere within the ConfirmationPage's onAfterRender or onDetach methods. Unfortunately, whenever I do this, the user is automatically redirected to the home page without a trace in the logs Any idea how to do that? Thanks Matt smime.p7s Description: S/MIME Cryptographic Signature
Re: Logout (Session destroy) on the last (stateful) page?
Does the redirect to the home page happen because of Wicket's default render strategy (REDIRECT_TO_BUFFER) that causes two requests? You invalidate session on the first which redirects to the buffered response. When the second request comes in expecting to get the already-rendered response, you get a new session. On Wed, Dec 1, 2010 at 11:53 AM, Martin Makundi < martin.maku...@koodaripalvelut.com> wrote: > Hi! > > I am curious too. For this reason we had to build our logoutpage so > that it invalidtes session logically but not in httpsession sense. > > Only clicking something from login page will do that. > > But it's a hack, I would like to know what's the proper way ;) > > ** > Martin > > > > 2010/12/1 Matthias Keller : > > Hi > > > > I've got the following problem: > > After a user completes a wizard, he sees a last confirmation page > containing > > some data, thus it must be a stateful page called by the following code > from > > the wizard: > >> > >> setResponsePage(new ConfirmationPage(myBean)); > > > > This ConfirmationPage must only be displayed once, thus if the user does > a > > refresh it must not be available anymore. > > I expected that I would be able to call session.invalidate() from > somewhere > > within the ConfirmationPage's onAfterRender or onDetach methods. > > Unfortunately, whenever I do this, the user is automatically redirected > to > > the home page without a trace in the logs > > Any idea how to do that? > > > > Thanks > > > > Matt > > > > > > - > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > >
Re: Logout (Session destroy) on the last (stateful) page?
Hi! I am curious too. For this reason we had to build our logoutpage so that it invalidtes session logically but not in httpsession sense. Only clicking something from login page will do that. But it's a hack, I would like to know what's the proper way ;) ** Martin 2010/12/1 Matthias Keller : > Hi > > I've got the following problem: > After a user completes a wizard, he sees a last confirmation page containing > some data, thus it must be a stateful page called by the following code from > the wizard: >> >> setResponsePage(new ConfirmationPage(myBean)); > > This ConfirmationPage must only be displayed once, thus if the user does a > refresh it must not be available anymore. > I expected that I would be able to call session.invalidate() from somewhere > within the ConfirmationPage's onAfterRender or onDetach methods. > Unfortunately, whenever I do this, the user is automatically redirected to > the home page without a trace in the logs > Any idea how to do that? > > Thanks > > Matt > > - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
