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" <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
>
