You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by ian silvester <ia...@is2.co.uk> on 2001/12/20 16:10:42 UTC

Re: logging a user out (thanks)

Many thanks Ralph.

I'll post the solution if I find an elegant one - I just like the idea that
a user goes away for lunch and comes back to see that they've been logged
out, without clicking a link to try to carry on what they were doing.

ian


----- Original Message -----
From: "Ralph Einfeldt" <ra...@uptime-isc.de>
To: "Tomcat Users List" <to...@jakarta.apache.org>
Sent: Thursday, December 20, 2001 2:55 PM
Subject: AW: logging a user out on session timeout with tomcat 3.2.3


beans are on the server side.

For that what you wan't you need either an applet
or you need some javascript that polls on the server.

> -----Ursprüngliche Nachricht-----
> Von: ian silvester [mailto:ians@is2.co.uk]
> Gesendet: Donnerstag, 20. Dezember 2001 15:36
> An: Tomcat User Mailing List
> Betreff: logging a user out on session timeout with tomcat 3.2.3
>
>
> Hi all,
>
> I have an implementation of Tomcat 3.2.3 on NT4sp6a. I would
> like for a
> user's browser to visually tell them that they've been
> 'logged out' of the
> system if their session times out. I do not want to put a
> test on a session
> attribute on every page with a redirect if fail, because
> that's just old and
> clunky and I'm sure there is a better way.
>
> I have created a bean that implements the HttpSessionBindingListener
> interface, which successfully writes to the console on
> session end - so far
> so good - but the console is at the server (obviously).
>
> My problem is that I would like to write to the browser
> window. I am of the
> understanding that beans are stored client-side, so that's
> looking good, but
> I can't find a way of getting an output stream from the bean
> to the browser
> window (something equivalent to response.getOutputStream).
>
> I'm aware BTW that Tomcat 4.0.1 (and therefore Servlets 2.3)
> offers much
> richer lifecycle objects, but an upgrade is unfortunately not
> an option
> (unless someone has a complete solution to the above under 4.0.1. I'm
> prepared to put forward the business case but only if its a surefire
> winner!)
>
> Any information about this would be very greatly appreciated.
>
> regards,
>
> Dr. Ian Silvester
>
>
>
> --
> To unsubscribe:   <ma...@jakarta.apache.org>
> For additional commands: <ma...@jakarta.apache.org>
> Troubles with the list: <ma...@jakarta.apache.org>
>
>
>

--
To unsubscribe:   <ma...@jakarta.apache.org>
For additional commands: <ma...@jakarta.apache.org>
Troubles with the list: <ma...@jakarta.apache.org>



--
To unsubscribe:   <ma...@jakarta.apache.org>
For additional commands: <ma...@jakarta.apache.org>
Troubles with the list: <ma...@jakarta.apache.org>