I did not mess with WaspSession.logoff at all. I am doing the following: 1. Set all my references I may have in my session to null 2. Clear all the page maps from the session 3. Call logoff(getScanManApp().getLogoffContext()); 4. Call login(context);
In my base page I am setting the headers so that the page is not cached. It seems to be working, and I am not able to back button on to the previous user's pages. And the session does not get invalidated. Do you see any problem doing it this way? > -----Original Message----- > From: Maurice Marrink [mailto:[EMAIL PROTECTED] > Sent: Tuesday, March 25, 2008 3:37 PM > To: [email protected] > Subject: Re: Wicket-Security Back Button and Login more than once > > > Logging off using WaspSession.logoff should by default invalidate the > session which would erase the user credentials of the new user. But i > am not sure what modifications you made, i remember us talking about > not invalidating the session but have no idea what you ultimately > decided on. > > The trick with reusing a session with different credentials is that > you do not want the new user to use the backbutton to access pages > available to the previous user but not to the current user. > You could use a http header for that (no-store i think) just override > setHeaders in your base-page(s). This will force the browser to make a > trip to the server even when using the backbutton. It will not prevent > the user from accessing pages the previous user visited if he also has > permission to access that page though. for that you really need a new > session. > > Maurice > > On Tue, Mar 25, 2008 at 11:14 PM, Warren > <[EMAIL PROTECTED]> wrote: > > Ok, that makes sense. > > > > Is there a problem logging off and then immediately logging a > new user on. I > > am doing this in the case that a > RestartResponseAtInterceptPageException was > > thrown but a different user logs on then the one that threw the > > RestartResponseAtInterceptPageException. I go to the home page > instead of > > continueToOriginalDestination(). I see that logging off causes > the Session > > to be marked dirty, but when I immediately log on a new user, > the session > > does not get invalidated. > > > > Do you see any reason why I should not do this? > > > > > > > -----Original Message----- > > > From: Maurice Marrink [mailto:[EMAIL PROTECTED] > > > > > > > Sent: Tuesday, March 25, 2008 2:19 PM > > > To: [email protected] > > > Subject: Re: Wicket-Security Back Button and Login more than once > > > > > > > > > I checked to be sure :) > > > we check it in the constructor: > > > // prevent double logins > > > if (isUserLoggedIn()) > > > { > > > throw new RestartResponseException(HomePage.class); > > > } > > > ofcourse that way you can not check if it is the same user. > > > So if you really want to do that you have to check it in the onsubmit > > > before you use the logincontext. > > > Our user object does have a password field which is encrypted so we > > > have to encrypt the user input first to match it against the > password. > > > However we do not store the user entity in the session but just the > > > id, during a request if the user is needed it is loaded once from the > > > db and then that is used throughout the request. after the request we > > > detach it again. > > > > > > Maurice > > > > > > On Tue, Mar 25, 2008 at 10:03 PM, Warren > > > <[EMAIL PROTECTED]> wrote: > > > > Your checking in your constructor or in an onSubmit() of a > form on your > > > > Login Page? I'm sorry, I am not quite following you. And are > > > you keeping > > > > password info in your User reference or are you looking it up > > > from db or > > > > wherever every time? > > > > > > > > > > > > > -----Original Message----- > > > > > From: Maurice Marrink [mailto:[EMAIL PROTECTED] > > > > > > > > > > > > > Sent: Tuesday, March 25, 2008 1:24 PM > > > > > To: [email protected] > > > > > Subject: Re: Wicket-Security Back Button and Login more > than once > > > > > > > > > > > > > > > Well, we do it by also keeping a reference to the user (not the > > > > > subject that swarm uses) in the session. > > > > > And we check if the the user is already logged in in > the constructor > > > > > of our login page. > > > > > The login context is not intended to check if the same user > > > is already > > > > > logged in. > > > > > The logincontext does however prevent (if so ordered, > which is the > > > > > case by default) multiple logins. > > > > > I don't think multiple logins is what you want, but if > that is the > > > > > case you could take a look at the constructors of > LoginContext, they > > > > > let you change the default behavior. > > > > > > > > > > Maurice > > > > > > > > > > On Tue, Mar 25, 2008 at 7:07 PM, Warren > > > > > <[EMAIL PROTECTED]> wrote: > > > > > > Where would you check to see if the same user was > trying to log > > > > > on again, in > > > > > > the LoginContext? I can check in the Session and see > if a user > > > > > is logged on > > > > > > or not, but I can not check to see if it is the same user > > > > > unless I keep the > > > > > > userid and password in the session. I would like to > do it in the > > > > > > LoginContext and throw an Exception if it is the same user. > > > > > The way it is > > > > > > now, I get a LoginException from the LoginContainer if I > > > try to log on > > > > > > again, but I have no way of knowing if it is because the same > > > > > user is logged > > > > > > on or not. > > > > > > > > > > > > public void login(LoginContext context) throws > > > LoginException > > > > > > { > > > > > > ... > > > > > > if (subjects.containsKey(key)) > > > > > > throw new LoginException("Already > > > > > logged in through this context > > > > > > ").setLoginContext(context); > > > > > > ... > > > > > > } > > > > > > > > > > > > How would you suggest figuring out if it is the same > user or not? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Maurice Marrink [mailto:[EMAIL PROTECTED] > > > > > > > Sent: Tuesday, March 25, 2008 10:02 AM > > > > > > > To: [email protected] > > > > > > > Subject: Re: Wicket-Security Back Button and Login more > > > than once > > > > > > > > > > > > > > > > > > > > > We also use a "screensaver" but it does not use the > > > login routines, > > > > > > > instead it just verifies the user input against > the username and > > > > > > > password from the loggedin user. > > > > > > > Also you can a check on the loginpage to determine if there > > > > > is already > > > > > > > a logged in user, if there is and it is the same username > > > > > you can skip > > > > > > > logging in again. > > > > > > > > > > > > > > Maurice > > > > > > > > > > > > > > On Tue, Mar 25, 2008 at 5:41 PM, Warren > > > > > > > <[EMAIL PROTECTED]> wrote: > > > > > > > > How do you deal with the situation where a user uses the > > > > > > > browser back button > > > > > > > > and ends up on a login page and then trys to > login again? In > > > > > > > other words, > > > > > > > > how do you allow a user to login more than > once. I am also > > > > > > > running into this > > > > > > > > same situation when I manually throw a > > > > > > > > RestartResponseAtInterceptPageException(Login.class) > > > exception. > > > > > > > > > > > > > > > > I need a 5 minute screen saver type of time out > and then the > > > > > > > regular session > > > > > > > > expired time out. The screen saver would > require the user to > > > > > > > login again and > > > > > > > > the pick-up where they left off, but if a new > user logged > > > > > in it would > > > > > > > > invalidate the previous users session and start > the new user > > > > > > > from the home > > > > > > > > page. I wrote something that kind of works, but I > > > keep running > > > > > > > into little > > > > > > > > problems with it. > > > > > > > > > > > > > > > > What would be the best way to do this? > > > > > > > > > > > > > > > > Thanks, > > > > > > > > > > > > > > > > Warren Bell > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > > > > > To unsubscribe, e-mail: > [EMAIL PROTECTED] > > > > > > > > For additional commands, e-mail: > [EMAIL PROTECTED] > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > > > > > For additional commands, e-mail: > [EMAIL PROTECTED] > > > > > > > > > > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
