I can't think of any other immediate problems, but i do find it
strange that the session is not invalidated.

Maurice

On Wed, Mar 26, 2008 at 1:10 AM, Warren <[EMAIL PROTECTED]> wrote:
> 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]
>
>

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

Reply via email to