Re: Logout (Session destroy) on the last (stateful) page?

[Matthias Keller]

Hi Ernesto




Thanks

Matt

On 2010-12-02 10:34, Ernesto Reinaldo Barreiro wrote:

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.

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

smime.p7s
Description: S/MIME Cryptographic Signature