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 <igor.vaynb...@gmail.com> 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 > <reier...@gmail.com> 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 >> <reier...@gmail.com> 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 >>> <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 >> >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org