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
<matthias.kel...@ergon.ch> 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
>> <matthias.kel...@ergon.ch>  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<matthias.kel...@ergon.ch>:
>>>>>>
>>>>>> 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

Reply via email to