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

2010-12-04 Thread robert.mcguinness

maybe i misunderstood, but wouldn't removing the page from the page map be
sufficient?   we do this for our confirmation pages that show sensitive data
(like temporary passwords).  
-- 
View this message in context: 
http://apache-wicket.1842946.n4.nabble.com/Logout-Session-destroy-on-the-last-stateful-page-tp3067753p3072309.html
Sent from the Users forum mailing list archive at Nabble.com.

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



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

2010-12-04 Thread Randy S.
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.comwrote:

 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 Kellermatthias.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



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

2010-12-03 Thread Igor Vaynberg
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 Kellermatthias.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



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

2010-12-03 Thread Ernesto Reinaldo Barreiro
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 Kellermatthias.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



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

2010-12-02 Thread Matthias Keller

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 Kellermatthias.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


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

2010-12-02 Thread Ernesto Reinaldo Barreiro
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 Kellermatthias.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



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

2010-12-02 Thread Matthias Keller

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.comwrote:


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 Kellermatthias.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


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

2010-12-02 Thread Ernesto Reinaldo Barreiro
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 Kellermatthias.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



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

2010-12-02 Thread Ernesto Reinaldo Barreiro
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 Kellermatthias.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



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

2010-12-01 Thread Martin Makundi
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



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

2010-12-01 Thread Randy S.
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