struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Charles" <char...@radworkz.com>
Subject Re: Ending a Session After Browser Has Gone Away
Date Fri, 02 Aug 2002 02:24:50 GMT
I had a similar requirement in my project. We had to prevent multiple users
from logging in at the same time and also to invalidate old sessions when
the user logs in again.

What we did is we created a singleton class that holds a hashtable that
stores the user id and its session object. Whenever a new user logs in, the
singleton class will perform a validation process: check the hashtable for
corresponding userid; if no similar userid found store the session object
and its user id in the hashtable. When he logs out the user id and session
object is removed from the hashtable.

In the event when a user logs in successfully and later another user with
the same userid logs in, the singleton class will invalidate the previous
login by retrieving its session object (using the userid as the key) and
invalidating it. An in the event when the user logs out unintentionally
(e.g. PC crashes), his/her userid and prvious session object is still stored
in the hashtable and the next time he/she logs in the old session can be
retrieved and invalidated.

Hope this helps

Charles

----- Original Message -----
From: "Cohan, Sean" <SCohan@goSPS.com>
To: "'Struts Users Mailing List'" <struts-user@jakarta.apache.org>
Sent: Friday, August 02, 2002 3:43 AM
Subject: RE: Ending a Session After Browser Has Gone Away


> Sorry Tony.  Proper thanks to you.
>
> There is a requirement that a user can't log in twice on their workstation
> or from another workstation.  I guess this is to prevent someone else from
> logging in to the business user's account when they are already logged in.
> But we don't the legitimate business user to wait till their session
expires
> before they can log in again.  We're actually discussing the merits of
this
> requirement as I write.
>
> Thanks to you too James.
>
> -----Original Message-----
> From: James Mitchell [mailto:jmitchtx@telocity.com]
> Sent: Thursday, August 01, 2002 3:01 PM
> To: Struts Users Mailing List
> Subject: RE: Ending a Session After Browser Has Gone Away
>
>
> Actually, I didn't point you to the session listener, someone else did ;)
>
> It sounds like you are having to keep track of users (of your application)
> and sessions on a one by one basis.
>
> So your business requirements state that 'Each user may only be logged in
at
> one time and disallow multiple sessionid per user'?
>
> Why would you want to 'lock' the user from the system (if a different
> session had not expired)?
>
> I would think that you only want to monitor it this way to provide
> additional functionality such as 'Resuming from a saved session' or
> 'Returning to a previous cart'
>
> It would be a little tricky, but I do see merit in it.  This way you could
> prevent someone from using IE to login and then login again in NS (just to
> make sure no cookies were shared).
>
> Well, good luck whatever you decide!!!
>
> James Mitchell
> Software Engineer\Struts Evangelist
> Struts-Atlanta, the "Open Minded Developer Network"
> http://www.open-tools.org/struts-atlanta
>
>
>
>
> > -----Original Message-----
> > From: Cohan, Sean [mailto:SCohan@goSPS.com]
> > Sent: Thursday, August 01, 2002 2:29 PM
> > To: 'Struts Users Mailing List'
> > Subject: RE: Ending a Session After Browser Has Gone Away
> >
> >
> > Thanks James for pointing me to the HttpSessionBindingListener.
> >
> > We can use that to 'unlock' the user's login id after the session
> > times out.
> > We still need to come up with a strategy where the user needs to
> > log back in
> > after a pc crash and reboot.  Not sure what our session timeout value
will
> > be, but if it's say 15 minutes, the user logs in, and the pc crashes
(not
> > from our app of course), the user would have to wait say 12
> > minutes for the
> > session to timeout before their lock would be released and they
> > could log in
> > again.
> >
> > That's why we're thinking of prompting them with a notice that they are
> > currently logged on and do they want to override that earlier logon.
> >
> > -----Original Message-----
> > From: Tony Baity [mailto:tonybaity@yahoo.com]
> > Sent: Thursday, August 01, 2002 11:45 AM
> > To: Struts Users Mailing List
> > Subject: RE: Ending a Session After Browser Has Gone Away
> >
> >
> >
> > Look in the javadocs for HttpSession and how to use
> > HttpSessionBindingListener .
> > I recommend allowing each browser instance to be allowed to
> > login. Try to be
> > stateless. If you want to do anything at all in the case of
> > session timeout,
> > use the  HttpSessionBindingListener
> >
> >
> >  Becky Moyer wrote:Just set a short session timeout. 3 minutes of
> > inactivity, session expires.
> > So by the time they reboot, they have to log in again.
> > Yeah, if someone stares at the page for 3 minutes and does something,
they
> > have to log in again, but if you're that concerned with sessions getting
> > cleared, then it's not such a big deal.
> >
> > Anything wrong with this?
> > Becky
> >
> > > -----Original Message-----
> > > From: Cohan, Sean [mailto:SCohan@goSPS.com]
> > > Sent: Thursday, August 01, 2002 11:33 AM
> > > To: 'Struts Users Mailing List'
> > > Subject: RE: Ending a Session After Browser Has Gone Away
> > >
> > >
> > > Any suggestions?
> > >
> > > -----Original Message-----
> > > From: James Mitchell [mailto:jmitchtx@telocity.com]
> > > Sent: Thursday, August 01, 2002 11:34 AM
> > > To: Struts Users Mailing List
> > > Subject: RE: Ending a Session After Browser Has Gone Away
> > >
> > >
> > > The web being the stateless environment that it is, you have no way
know
> > > (without using javascript) that a user has closed a browser.
> > >
> > > I wouldn't advise to doing this anyway, because the user may have
> > > more than
> > > one window open, so if they close one of them and try to continue
> > > using your
> > > site, they will be met (rather rudely) with your login screens.
> > >
> > > I can't speak for other people, but whenever I'm navigating a
> > > site that does
> > > a shit job of navigation hierarchy, I always use shift+click if
> > I want to
> > > keep the current page and not be sent off deep in the site with
> > no hope of
> > > finding the original spot that sent me. If the site did as you
propose,
> > > this would result in a very pissed off user. And you could bet
> > that you'd
> > > hear about it (from me at least).
> > >
> > > Oh well, that's my 2 cents.
> > >
> > >
> > >
> > > James Mitchell
> > > Software Engineer\Struts Evangelist
> > > Struts-Atlanta, the "Open Minded Developer Network"
> > > http://www.open-tools.org/struts-atlanta
> > >
> > >
> > >
> > >
> > > > -----Original Message-----
> > > > From: Cohan, Sean [mailto:SCohan@goSPS.com]
> > > > Sent: Thursday, August 01, 2002 11:06 AM
> > > > To: struts-user@jakarta.apache.org
> > > > Subject: Ending a Session After Browser Has Gone Away
> > > >
> > > >
> > > > Is there a way to end a user session if the browser has closed
either
> > > > through user action or non-user actions such as power outages?
> > > > If not, what
> > > > are typical ways to get around this? We are talking about
> > > > allowing the user
> > > > to login again, checking for a current user session, and if
> > > they have one,
> > > > killing it and starting a new one. Is this a sound approach? Thanks.
> > > >
> > > >
> > > > Sean Cohan
> > > > Software Performance Systems
> > > >
> > > >
> > > >
> > > > --
> > > > To unsubscribe, e-mail:
> > > >
> > > > For additional commands, e-mail:
> > > >
> > > >
> > > >
> > >
> > >
> > > --
> > > To unsubscribe, e-mail:
> > >
> > > For additional commands, e-mail:
> > >
> > >
> > > --
> > > To unsubscribe, e-mail:
> > >
> > > For additional commands, e-mail:
> > >
> > >
> >
> >
> > --
> > To unsubscribe, e-mail:
> > For additional commands, e-mail:
> >
> >
> >
> > ---------------------------------
> > Do You Yahoo!?
> > Yahoo! Health - Feel better, live better
> >
> > --
> > To unsubscribe, e-mail:
> <mailto:struts-user-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail:
> <mailto:struts-user-help@jakarta.apache.org>
>
>
>
> --
> To unsubscribe, e-mail:
> <mailto:struts-user-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail:
> <mailto:struts-user-help@jakarta.apache.org>
>
> --
> To unsubscribe, e-mail:
<mailto:struts-user-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail:
<mailto:struts-user-help@jakarta.apache.org>
>
>
>



--
To unsubscribe, e-mail:   <mailto:struts-user-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:struts-user-help@jakarta.apache.org>


Mime
View raw message