Re: logout on session destroy

[Francois Meillet]

You can write a unboundListener and register it in your sessionStore.
This code should be in your application init()

getSessionStore().registerUnboundListener( new ISessionStore.UnboundListener() {
@Override
public void sessionUnbound(String sessionId) {
// logout timestamp in the database
}
});


François Meillet
Formation Wicket - Développement Wicket





Le 15 nov. 2013 à 23:19, Dirk Wichmann dir...@team-wichmann.de a écrit :

 Hi all,
 
 it's quite frustrating, a simple thing gets complicated.
 I have a Webapp with login page and logout button.
 If the user clicks the logout I write a logout timestamp in the database.
 Now I want to write the same timestamp when the session expires.
 Only thing I have found on the Web is to use
 WebApplication.sessionUnbound with Session ID.
 When this method is called the AuthenticatedWebSession is still dead I
 think or maybe I cant get the Object.
 Other thing I found is the method onInvalidate() in the webSession, but
 this method is never called. (i'm on Wicket 6.1.)
 
 What is the right way to do the trick??
 
 Thanks in advance
 Dirk
 
 -
 To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
 For additional commands, e-mail: users-h...@wicket.apache.org
 

Re: logout on session destroy

[Dirk Wichmann]

Thanks, that works, but how can I get my WebSession Object??
In there the user is stored and I need the id of the user.
WebSession.get() does not work

Thanks in advance
Dirk


Am 16.11.2013 11:04, schrieb Francois Meillet:
 You can write a unboundListener and register it in your sessionStore.
 This code should be in your application init()

 getSessionStore().registerUnboundListener( new 
 ISessionStore.UnboundListener() {
   @Override
   public void sessionUnbound(String sessionId) {
   // logout timestamp in the database
   }
 });


 François Meillet
 Formation Wicket - Développement Wicket





 Le 15 nov. 2013 à 23:19, Dirk Wichmann dir...@team-wichmann.de a écrit :

 Hi all,

 it's quite frustrating, a simple thing gets complicated.
 I have a Webapp with login page and logout button.
 If the user clicks the logout I write a logout timestamp in the database.
 Now I want to write the same timestamp when the session expires.
 Only thing I have found on the Web is to use
 WebApplication.sessionUnbound with Session ID.
 When this method is called the AuthenticatedWebSession is still dead I
 think or maybe I cant get the Object.
 Other thing I found is the method onInvalidate() in the webSession, but
 this method is never called. (i'm on Wicket 6.1.)

 What is the right way to do the trick??

 Thanks in advance
 Dirk

 -
 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 on session destroy

[Ernesto Reinaldo Barreiro]

Maybe bind sessionId with user ID when session is created? on a persistence
storage? So that you can recover user ID with the session Id


On Sat, Nov 16, 2013 at 12:19 PM, Dirk Wichmann dir...@team-wichmann.dewrote:

 Thanks, that works, but how can I get my WebSession Object??
 In there the user is stored and I need the id of the user.
 WebSession.get() does not work

 Thanks in advance
 Dirk


 Am 16.11.2013 11:04, schrieb Francois Meillet:
  You can write a unboundListener and register it in your sessionStore.
  This code should be in your application init()
 
  getSessionStore().registerUnboundListener( new
 ISessionStore.UnboundListener() {
@Override
public void sessionUnbound(String sessionId) {
// logout timestamp in the database
}
  });
 
 
  François Meillet
  Formation Wicket - Développement Wicket
 
 
 
 
 
  Le 15 nov. 2013 à 23:19, Dirk Wichmann dir...@team-wichmann.de a
 écrit :
 
  Hi all,
 
  it's quite frustrating, a simple thing gets complicated.
  I have a Webapp with login page and logout button.
  If the user clicks the logout I write a logout timestamp in the
 database.
  Now I want to write the same timestamp when the session expires.
  Only thing I have found on the Web is to use
  WebApplication.sessionUnbound with Session ID.
  When this method is called the AuthenticatedWebSession is still dead I
  think or maybe I cant get the Object.
  Other thing I found is the method onInvalidate() in the webSession, but
  this method is never called. (i'm on Wicket 6.1.)
 
  What is the right way to do the trick??
 
  Thanks in advance
  Dirk
 
  -
  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




-- 
Regards - Ernesto Reinaldo Barreiro

Re: logout on session destroy

[Francois Meillet]

In this case, override the onInvalidate() method in your custom session.

from the api : 
onInvalidate is a callback method that is executed when the user session is 
invalidated
either by explicit call to {@link org.apache.wicket.Session#invalidate()}
or due to HttpSession expiration.


François Meillet
Formation Wicket - Développement Wicket





Le 16 nov. 2013 à 12:19, Dirk Wichmann dir...@team-wichmann.de a écrit :

 Thanks, that works, but how can I get my WebSession Object??
 In there the user is stored and I need the id of the user.
 WebSession.get() does not work
 
 Thanks in advance
 Dirk
 
 
 Am 16.11.2013 11:04, schrieb Francois Meillet:
 You can write a unboundListener and register it in your sessionStore.
 This code should be in your application init()
 
 getSessionStore().registerUnboundListener( new 
 ISessionStore.UnboundListener() {
  @Override
  public void sessionUnbound(String sessionId) {
  // logout timestamp in the database
  }
 });
 
 
 François Meillet
 Formation Wicket - Développement Wicket
 
 
 
 
 
 Le 15 nov. 2013 à 23:19, Dirk Wichmann dir...@team-wichmann.de a écrit :
 
 Hi all,
 
 it's quite frustrating, a simple thing gets complicated.
 I have a Webapp with login page and logout button.
 If the user clicks the logout I write a logout timestamp in the database.
 Now I want to write the same timestamp when the session expires.
 Only thing I have found on the Web is to use
 WebApplication.sessionUnbound with Session ID.
 When this method is called the AuthenticatedWebSession is still dead I
 think or maybe I cant get the Object.
 Other thing I found is the method onInvalidate() in the webSession, but
 this method is never called. (i'm on Wicket 6.1.)
 
 What is the right way to do the trick??
 
 Thanks in advance
 Dirk
 
 -
 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 on session destroy

[Dirk Wichmann]

sorry, there is no methode onInvalidate() to overwrite??

not in AuthenticatedWebSession or WebSession or in Session (I use Wicket
6.1)


Am 16.11.2013 12:47, schrieb Francois Meillet:
 In this case, override the onInvalidate() method in your custom session.

 from the api : 
 onInvalidate is a callback method that is executed when the user session is 
 invalidated
 either by explicit call to {@link org.apache.wicket.Session#invalidate()}
 or due to HttpSession expiration.


 François Meillet
 Formation Wicket - Développement Wicket





 Le 16 nov. 2013 à 12:19, Dirk Wichmann dir...@team-wichmann.de a écrit :

 Thanks, that works, but how can I get my WebSession Object??
 In there the user is stored and I need the id of the user.
 WebSession.get() does not work

 Thanks in advance
 Dirk


 Am 16.11.2013 11:04, schrieb Francois Meillet:
 You can write a unboundListener and register it in your sessionStore.
 This code should be in your application init()

 getSessionStore().registerUnboundListener( new 
 ISessionStore.UnboundListener() {
 @Override
 public void sessionUnbound(String sessionId) {
 // logout timestamp in the database
 }
 });


 François Meillet
 Formation Wicket - Développement Wicket





 Le 15 nov. 2013 à 23:19, Dirk Wichmann dir...@team-wichmann.de a écrit :

 Hi all,

 it's quite frustrating, a simple thing gets complicated.
 I have a Webapp with login page and logout button.
 If the user clicks the logout I write a logout timestamp in the database.
 Now I want to write the same timestamp when the session expires.
 Only thing I have found on the Web is to use
 WebApplication.sessionUnbound with Session ID.
 When this method is called the AuthenticatedWebSession is still dead I
 think or maybe I cant get the Object.
 Other thing I found is the method onInvalidate() in the webSession, but
 this method is never called. (i'm on Wicket 6.1.)

 What is the right way to do the trick??

 Thanks in advance
 Dirk

 -
 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 on session destroy

[Francois Meillet]

Update to the 6.12 version or follow Ernesto's advice or write your own 
HttpSessionStore.
 
François Meillet
Formation Wicket - Développement Wicket





Le 16 nov. 2013 à 13:17, Dirk Wichmann dir...@team-wichmann.de a écrit :

 sorry, there is no methode onInvalidate() to overwrite??
 
 not in AuthenticatedWebSession or WebSession or in Session (I use Wicket
 6.1)
 
 
 Am 16.11.2013 12:47, schrieb Francois Meillet:
 In this case, override the onInvalidate() method in your custom session.
 
 from the api : 
 onInvalidate is a callback method that is executed when the user session is 
 invalidated
 either by explicit call to {@link org.apache.wicket.Session#invalidate()}
 or due to HttpSession expiration.
 
 
 François Meillet
 Formation Wicket - Développement Wicket
 
 
 
 
 
 Le 16 nov. 2013 à 12:19, Dirk Wichmann dir...@team-wichmann.de a écrit :
 
 Thanks, that works, but how can I get my WebSession Object??
 In there the user is stored and I need the id of the user.
 WebSession.get() does not work
 
 Thanks in advance
 Dirk
 
 
 Am 16.11.2013 11:04, schrieb Francois Meillet:
 You can write a unboundListener and register it in your sessionStore.
 This code should be in your application init()
 
 getSessionStore().registerUnboundListener( new 
 ISessionStore.UnboundListener() {
@Override
public void sessionUnbound(String sessionId) {
// logout timestamp in the database
}
 });
 
 
 François Meillet
 Formation Wicket - Développement Wicket
 
 
 
 
 
 Le 15 nov. 2013 à 23:19, Dirk Wichmann dir...@team-wichmann.de a écrit :
 
 Hi all,
 
 it's quite frustrating, a simple thing gets complicated.
 I have a Webapp with login page and logout button.
 If the user clicks the logout I write a logout timestamp in the database.
 Now I want to write the same timestamp when the session expires.
 Only thing I have found on the Web is to use
 WebApplication.sessionUnbound with Session ID.
 When this method is called the AuthenticatedWebSession is still dead I
 think or maybe I cant get the Object.
 Other thing I found is the method onInvalidate() in the webSession, but
 this method is never called. (i'm on Wicket 6.1.)
 
 What is the right way to do the trick??
 
 Thanks in advance
 Dirk
 
 -
 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 on session destroy

[Dirk Wichmann]

I have updated to 6.12 (without any pane, fantastic... I cannot believe
that it was so easy)

Thanks a lot now it works

Cheers
Dirk

Am 16.11.2013 14:05, schrieb Francois Meillet:
 Update to the 6.12 version or follow Ernesto's advice or write your own 
 HttpSessionStore.
  
 François Meillet
 Formation Wicket - Développement Wicket





 Le 16 nov. 2013 à 13:17, Dirk Wichmann dir...@team-wichmann.de a écrit :

 sorry, there is no methode onInvalidate() to overwrite??

 not in AuthenticatedWebSession or WebSession or in Session (I use Wicket
 6.1)


 Am 16.11.2013 12:47, schrieb Francois Meillet:
 In this case, override the onInvalidate() method in your custom session.

 from the api : 
 onInvalidate is a callback method that is executed when the user session is 
 invalidated
 either by explicit call to {@link org.apache.wicket.Session#invalidate()}
 or due to HttpSession expiration.


 François Meillet
 Formation Wicket - Développement Wicket





 Le 16 nov. 2013 à 12:19, Dirk Wichmann dir...@team-wichmann.de a écrit :

 Thanks, that works, but how can I get my WebSession Object??
 In there the user is stored and I need the id of the user.
 WebSession.get() does not work

 Thanks in advance
 Dirk


 Am 16.11.2013 11:04, schrieb Francois Meillet:
 You can write a unboundListener and register it in your sessionStore.
 This code should be in your application init()

 getSessionStore().registerUnboundListener( new 
 ISessionStore.UnboundListener() {
   @Override
   public void sessionUnbound(String sessionId) {
   // logout timestamp in the database
   }
 });


 François Meillet
 Formation Wicket - Développement Wicket





 Le 15 nov. 2013 à 23:19, Dirk Wichmann dir...@team-wichmann.de a écrit :

 Hi all,

 it's quite frustrating, a simple thing gets complicated.
 I have a Webapp with login page and logout button.
 If the user clicks the logout I write a logout timestamp in the database.
 Now I want to write the same timestamp when the session expires.
 Only thing I have found on the Web is to use
 WebApplication.sessionUnbound with Session ID.
 When this method is called the AuthenticatedWebSession is still dead I
 think or maybe I cant get the Object.
 Other thing I found is the method onInvalidate() in the webSession, but
 this method is never called. (i'm on Wicket 6.1.)

 What is the right way to do the trick??

 Thanks in advance
 Dirk

 -
 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




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

Re: logout

[Tom Eugelink]

Ok. The actual problem I have is that wicket auth keeps logging in 
automatically. This is a side effect of a.o. BASIC authentication (not sure if 
that is used in this case, but the behavior is similar) which sends the login 
credentials with every request, even if you have logged out in the mean time. 
To enforce a new login via the login page, one usually places some marker in 
the session telling the authenticator class that it should not accept the 
current credentials until a valid login page submit was done. But since Wicket 
keeps doing things to the session, I'm not able to get this marker to work.

Are there any people using auth and that are able to fully log out?

Tom


On 2012-06-25 13:29, Martin Grigorov wrote:

Hi Tom,

I agree with your vision.
But since Wicket is a framework around the Servlet API we call
HttpSession.invalidate(). This triggers some web container internal
workings and at some point Wicket is called back (see
javax.servlet.http.HttpSessionListener/HttpSessionBindingListener) and
Wicket clears everything that it added to this session.
What happens with this session later is not our business. It may be
teared down or recycled, we really don't care. Next time we need to
store something in the http session we just call:
httpRequest.getSession(true) and use it.

I know you use recent version of Wicket (6.x ?) and there are no
pagemaps since Wicket 1.5.0 but if you find that anything leaks then
it is a bug and it should be fixed.

On Sat, Jun 23, 2012 at 11:31 AM, Tom Eugelink t...@tbee.org wrote:

Which means that upon logout, these values should be removed / cleared. A
session does not represent a user, it is a construct to bind request, no
more no less. All other usages are bolted on and should be bolted off. You
don't tear down the house, just because you are moving.

Tom


On 2012-06-23 10:18, Bert wrote:

But Wicket also stores the page map in the session to support back
button functionality. If you only change the status, than the user
could possibly (depending on how you construct your page) go back
after the logout and see the last pages.

This could be a problem on public computers.

You could also see a session as representing a user, not a browser.
Than, invalidating the session on logout makes perfect sense to me.

regards



-
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

[Martin Grigorov]

wicket-auth-roles is actually an example of IAuthenticationStrategy
and IAuthorizationStrategy interfaces.
Most of the people that use it actually just see how it works and
copy/paste the related parts of it and later extend them with their
specific business logic.

afaik it uses rememberMe cookie but it is removed when you log out.
Put a breakpoint in CookieUtils#remove(String) and you will see
whether this really happens. Another interesting point in
AuthenticatedWebSession#invalidate().
You can also use Firebug/Dev utils to see what cookies are left after
logout and whether they are send with the next request and used to log
you in.

On Mon, Jun 25, 2012 at 2:38 PM, Tom Eugelink t...@tbee.org wrote:
 Ok. The actual problem I have is that wicket auth keeps logging in
 automatically. This is a side effect of a.o. BASIC authentication (not sure
 if that is used in this case, but the behavior is similar) which sends the
 login credentials with every request, even if you have logged out in the
 mean time. To enforce a new login via the login page, one usually places
 some marker in the session telling the authenticator class that it should
 not accept the current credentials until a valid login page submit was done.
 But since Wicket keeps doing things to the session, I'm not able to get this
 marker to work.

 Are there any people using auth and that are able to fully log out?

 Tom



 On 2012-06-25 13:29, Martin Grigorov wrote:

 Hi Tom,

 I agree with your vision.
 But since Wicket is a framework around the Servlet API we call
 HttpSession.invalidate(). This triggers some web container internal
 workings and at some point Wicket is called back (see
 javax.servlet.http.HttpSessionListener/HttpSessionBindingListener) and
 Wicket clears everything that it added to this session.
 What happens with this session later is not our business. It may be
 teared down or recycled, we really don't care. Next time we need to
 store something in the http session we just call:
 httpRequest.getSession(true) and use it.

 I know you use recent version of Wicket (6.x ?) and there are no
 pagemaps since Wicket 1.5.0 but if you find that anything leaks then
 it is a bug and it should be fixed.

 On Sat, Jun 23, 2012 at 11:31 AM, Tom Eugelink t...@tbee.org wrote:

 Which means that upon logout, these values should be removed / cleared. A
 session does not represent a user, it is a construct to bind request, no
 more no less. All other usages are bolted on and should be bolted off.
 You
 don't tear down the house, just because you are moving.

 Tom


 On 2012-06-23 10:18, Bert wrote:

 But Wicket also stores the page map in the session to support back
 button functionality. If you only change the status, than the user
 could possibly (depending on how you construct your page) go back
 after the logout and see the last pages.

 This could be a problem on public computers.

 You could also see a session as representing a user, not a browser.
 Than, invalidating the session on logout makes perfect sense to me.

 regards


 -
 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




-- 
Martin Grigorov
jWeekend
Training, Consulting, Development
http://jWeekend.com

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

Re: logout

[Stefan Moises]

Hi Tom,

we are using wicket auth and we can only logout if we use a dedicated 
Signout page (with template) - if we only logout (and e.g. try to 
forward right to the homepage with setResponsePage()) it doesn't work 
and the user always stays logged in as you describe it.
We'd love to get rid of the additional Signout page though (because it 
only says Good bye and is rather annoying for regular users I think 
...) :)


Stefan

Am 25.06.2012 13:38, schrieb Tom Eugelink:
Ok. The actual problem I have is that wicket auth keeps logging in 
automatically. This is a side effect of a.o. BASIC authentication (not 
sure if that is used in this case, but the behavior is similar) which 
sends the login credentials with every request, even if you have 
logged out in the mean time. To enforce a new login via the login 
page, one usually places some marker in the session telling the 
authenticator class that it should not accept the current credentials 
until a valid login page submit was done. But since Wicket keeps doing 
things to the session, I'm not able to get this marker to work.


Are there any people using auth and that are able to fully log out?

Tom


On 2012-06-25 13:29, Martin Grigorov wrote:

Hi Tom,

I agree with your vision.
But since Wicket is a framework around the Servlet API we call
HttpSession.invalidate(). This triggers some web container internal
workings and at some point Wicket is called back (see
javax.servlet.http.HttpSessionListener/HttpSessionBindingListener) and
Wicket clears everything that it added to this session.
What happens with this session later is not our business. It may be
teared down or recycled, we really don't care. Next time we need to
store something in the http session we just call:
httpRequest.getSession(true) and use it.

I know you use recent version of Wicket (6.x ?) and there are no
pagemaps since Wicket 1.5.0 but if you find that anything leaks then
it is a bug and it should be fixed.

On Sat, Jun 23, 2012 at 11:31 AM, Tom Eugelink t...@tbee.org wrote:
Which means that upon logout, these values should be removed / 
cleared. A
session does not represent a user, it is a construct to bind 
request, no
more no less. All other usages are bolted on and should be bolted 
off. You

don't tear down the house, just because you are moving.

Tom


On 2012-06-23 10:18, Bert wrote:

But Wicket also stores the page map in the session to support back
button functionality. If you only change the status, than the user
could possibly (depending on how you construct your page) go back
after the logout and see the last pages.

This could be a problem on public computers.

You could also see a session as representing a user, not a browser.
Than, invalidating the session on logout makes perfect sense to me.

regards



-
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

[Tom Eugelink]

Ok. I also have a logout page, call signout in the before-render, and then use 
the exception thing to immediately forward to another page. Maybe actually 
showing the logout page is the trick (better a page and autologin all the time).

What do you do on the logout page to force the logout?

Tom


On 2012-06-25 13:58, Stefan Moises wrote:

Hi Tom,

we are using wicket auth and we can only logout if we use a dedicated Signout 
page (with template) - if we only logout (and e.g. try to forward right to the 
homepage with setResponsePage()) it doesn't work and the user always stays 
logged in as you describe it.
We'd love to get rid of the additional Signout page though (because it only says 
Good bye and is rather annoying for regular users I think ...) :)

Stefan

Am 25.06.2012 13:38, schrieb Tom Eugelink:

Ok. The actual problem I have is that wicket auth keeps logging in 
automatically. This is a side effect of a.o. BASIC authentication (not sure if 
that is used in this case, but the behavior is similar) which sends the login 
credentials with every request, even if you have logged out in the mean time. 
To enforce a new login via the login page, one usually places some marker in 
the session telling the authenticator class that it should not accept the 
current credentials until a valid login page submit was done. But since Wicket 
keeps doing things to the session, I'm not able to get this marker to work.

Are there any people using auth and that are able to fully log out?

Tom


On 2012-06-25 13:29, Martin Grigorov wrote:

Hi Tom,

I agree with your vision.
But since Wicket is a framework around the Servlet API we call
HttpSession.invalidate(). This triggers some web container internal
workings and at some point Wicket is called back (see
javax.servlet.http.HttpSessionListener/HttpSessionBindingListener) and
Wicket clears everything that it added to this session.
What happens with this session later is not our business. It may be
teared down or recycled, we really don't care. Next time we need to
store something in the http session we just call:
httpRequest.getSession(true) and use it.

I know you use recent version of Wicket (6.x ?) and there are no
pagemaps since Wicket 1.5.0 but if you find that anything leaks then
it is a bug and it should be fixed.

On Sat, Jun 23, 2012 at 11:31 AM, Tom Eugelink t...@tbee.org wrote:

Which means that upon logout, these values should be removed / cleared. A
session does not represent a user, it is a construct to bind request, no
more no less. All other usages are bolted on and should be bolted off. You
don't tear down the house, just because you are moving.

Tom


On 2012-06-23 10:18, Bert wrote:

But Wicket also stores the page map in the session to support back
button functionality. If you only change the status, than the user
could possibly (depending on how you construct your page) go back
after the logout and see the last pages.

This could be a problem on public computers.

You could also see a session as representing a user, not a browser.
Than, invalidating the session on logout makes perfect sense to me.

regards



-
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





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

Re: logout

[Tom Eugelink]

On 2012-06-22 16:57, Tom Eugelink wrote:

Anyhow, I've added Wicket Auth/Roles 
(http://wicket.apache.org/learn/projects/authroles.html) as the security 
framework and it is working fine except one thing; logging out.


I've found that the login / logout logic is invalidating the session. During an 
attempt to setup security in a webapp years back, I found that Tomcat also does 
this and I never understood why. The session is a technical construct that 
binds requests from the same browser and allows the website to become coherent 
over multiple request. It has nothing to do with an authentication state. 
Naturally it can be used as a means to administer if a user is logged in, but 
there is no reason to trash the session when a user is logging out; after all, 
it's still the same brower sending requests. The session has not changed, the 
user's status has.

The security filter I've implemented years back as a result of this discovery 
simply changes the logged in state in the current session. If any attributes 
need to be cleared when a user logs out, this is easily done by removing them 
from the current session (may even by using a special map store as an attribute 
in the session). This will prevent the automatic login I'm experiencing now. I 
will roll my security filter in to my wicket app.

Tom

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

Re: logout

[Bert]

But Wicket also stores the page map in the session to support back
button functionality. If you only change the status, than the user
could possibly (depending on how you construct your page) go back
after the logout and see the last pages.

This could be a problem on public computers.

You could also see a session as representing a user, not a browser.
Than, invalidating the session on logout makes perfect sense to me.

regards

On Sat, Jun 23, 2012 at 9:14 AM, Tom Eugelink t...@tbee.org wrote:
 On 2012-06-22 16:57, Tom Eugelink wrote:

 Anyhow, I've added Wicket Auth/Roles
 (http://wicket.apache.org/learn/projects/authroles.html) as the security
 framework and it is working fine except one thing; logging out.


 I've found that the login / logout logic is invalidating the session. During
 an attempt to setup security in a webapp years back, I found that Tomcat
 also does this and I never understood why. The session is a technical
 construct that binds requests from the same browser and allows the website
 to become coherent over multiple request. It has nothing to do with an
 authentication state. Naturally it can be used as a means to administer if a
 user is logged in, but there is no reason to trash the session when a user
 is logging out; after all, it's still the same brower sending requests. The
 session has not changed, the user's status has.

 The security filter I've implemented years back as a result of this
 discovery simply changes the logged in state in the current session. If any
 attributes need to be cleared when a user logs out, this is easily done by
 removing them from the current session (may even by using a special map
 store as an attribute in the session). This will prevent the automatic login
 I'm experiencing now. I will roll my security filter in to my wicket app.


 Tom

 -
 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

[Tom Eugelink]

Which means that upon logout, these values should be removed / cleared. A 
session does not represent a user, it is a construct to bind request, no more 
no less. All other usages are bolted on and should be bolted off. You don't 
tear down the house, just because you are moving.

Tom

On 2012-06-23 10:18, Bert wrote:

But Wicket also stores the page map in the session to support back
button functionality. If you only change the status, than the user
could possibly (depending on how you construct your page) go back
after the logout and see the last pages.

This could be a problem on public computers.

You could also see a session as representing a user, not a browser.
Than, invalidating the session on logout makes perfect sense to me.

regards




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

[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?

[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?

[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?

[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?

[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?

[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?

[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?

[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?

[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?

[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?

[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

Re: logout

[Nino Saturnino Martinez Vazquez Wael]

session.invalidate() and use setResponsePage to navigate to where you 
want when pressing back button (Thinking its not the browser button?)


-Nino

tbt wrote:

Hi

I'm a newbie to wicket and i'm currently using a Session to log users into
my application. When the users click a logout button a new page is shown.
But they can click the back button in the browser and go into the
application. Is there a wicket way of expiring the session when the logout
button is clicked and showing a seperate page when the back button is
clicked.

thanks
  


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: logout

[tbt]

well it is the browser button that i'm concerned about :) 
I want it to be something like a mail account where once you logout you
can't use the back button in the browser to navigate inside the
application(eg: yahoo mail).


Nino.Martinez wrote:
 
 session.invalidate() and use setResponsePage to navigate to where you 
 want when pressing back button (Thinking its not the browser button?)
 
 -Nino
 
 tbt wrote:
 Hi

 I'm a newbie to wicket and i'm currently using a Session to log users
 into
 my application. When the users click a logout button a new page is shown.
 But they can click the back button in the browser and go into the
 application. Is there a wicket way of expiring the session when the
 logout
 button is clicked and showing a seperate page when the back button is
 clicked.

 thanks
   
 
 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]
 
 
 

-- 
View this message in context: 
http://www.nabble.com/logout-tf4592416.html#a13111382
Sent from the Wicket - User mailing list archive at Nabble.com.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]