Hi Jeremy,
What we usually implement in our applications is a server-side timeout
(like the one you have with httpSessions) so when users try to access
again, they are redirected to a page and they are told their session has
timed-out and they are offered the option of login in again. We thought
that most of the times the session times out because the user is not
there any more (meaning he closed the browser window, he went out for a
walk...) and why try to notify inmediatly somebody that is not there? So
we decided to notify them when they try to do something again. Our
security system gives you an appropriate message(bad password, user
doesn't exist... ) so "your session has timed out" is just another kind
of message. Given the way the www works, through a connectionless
protocol(as Craig explained), we thought that it was the more balanced
(user friendliness/development effor+client requirements) way of
handling it.
Just my 2c,
Dan
-------------------------------------------
Daniel Lopez Janariz ([EMAIL PROTECTED])
Web Services
Computer Center
Balearic Islands University
-------------------------------------------
Jeremy Young wrote:
>
> Thanks Craig,
>
> We're moving towards the idea of some client side timeout which will
> redirect to a page which forces a relogin.
>
> JRY
>
> -----Original Message-----
> From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]]
> Sent: 22 January 2000 05:04
> To: Jeremy Young; [EMAIL PROTECTED]`
> Subject: Re: Session timeout
>
> Jeremy Young wrote:
>
> > Hi all
> >
> > Can anyone tell me how I can notify a client that a session has timed out?
> > Presumably I create an object which implements HttpSessionBindingListener,
> > but how do I get that object to notify the client
>
> You will understand why this is not possible in the general case when you
> remember
> a key feature of the HTTP protocol -- there is not a general-purpose two-way
> socket connection between client and browser in between requests. (The
> HTTP/1.1
> ability to maintain a persistent connection is a performance improvement,
> but it
> does not create a two-way street.)
>
> Now, consider the following scenarios:
>
> * The client browser is running on a multi-user computer, so all
> users on that computer have the same IP address. There is no
> way to physically address a particular browser, because they are
> not waiting for a connection.
>
> * The client browser is running behind a proxy server, and perhaps
> has an IP address in the range reserved for intranets (such as
> 192.168.137.xxx) which cannot be accessed at all from the Internet.
>
> The bottom line -- if you need proactive notification for events like this,
> you
> need to use a protocol other than HTTP.
>
> > - ie pushing a page? Is
> > this possible?
>
> If you look inside most "push" type technologies, they really are not push
> oriented -- what is happening instead is that the client is periodically
> polling
> to check for new events of interest. You could arrange a protocol like that
> if
> you wanted, by having a page with an auto-refresh interval set, or an applet
> that
> periodically requested an update. The problem you will run into, though, is
> that
> the definition of a session timeout is that the time *between* requests
> exceeds
> whatever limit you have set. If you set your session timeout to, say, five
> minutes, but you have your client doing polling every one minute, the
> session will
> never expire as long as the client is running.
>
> > Jeremy Young
>
> Craig McClanahan
===========================================================================
To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff JSP-INTEREST".
FAQs on JSP can be found at:
http://java.sun.com/products/jsp/faq.html
http://www.esperanto.org.nz/jsp/jspfaq.html
