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
