For logout, you can implement a HttpSessionListener .
It has got a method:

public void sessionDestroyed(HttpSessionEvent se)

It's invoked when http session is invalidated. ( session.invalidated() )

So, you have to invalidate http session when user makes logout ( i.e, user
clicks a logout button and calls a servlet )
To capture when user is closing the browser , you need use javascript events
and throw a call to the server. Maybe, a filter can be use to capture this
event

For login, you can use Spring Security
Maybe for logout too, but I don't know it
Or your use your own filters




2011/10/6 Martin O'Shea <app...@dsl.pipex.com>

> I need to be able to intercept a successful authentication of a login /
> logout request which can then be used to make a series of system updates to
> record the fact.
>
> So, if John Doe has just logged in successfully, an update is made to his
> session like:
>
> session.setAttribute("loggedIntoSession", true);
>
> Or an update made to the database?
>
> Conversely, upon logout:
>
> session.setAttribute("loggedIntoSession", false);
>
> At the moment, I am thinking about scriptlets in the pages served testing
> the request's servlet path after login is successful but is a filter better?
> But if so, what might a filter check for?
>
> -----Original Message-----
> From: Martin O'Shea [mailto:app...@dsl.pipex.com]
> Sent: 05 Oct 2011 23 06
> To: 'Tomcat Users List'
> Subject: RE: Using multiple login pages
>
> Thanks for this Chris. It is food for thought.
>
> I was under the impression that <form-login-page> was static, because
> that's how I seen it used in apps I've worked on.
>
> But I am curious to try a filter as well, something like this mapped to the
> login:
>
> public void doFilter(ServletRequest request, ServletResponse response,
> FilterChain chain) throws java.io.IOException, ServletException {
>
>
>      HttpServletRequest req = (HttpServletRequest)request;
>      HttpServletResponse res = (HttpServletResponse)response;
>
>      // pre login action
>
>      // get username
>      String username = req.getParameter("j_username");
>
>      // if user is in revoked list send error
>      if ( revokeList.contains(username) ) {
>      res.sendError(javax.servlet.http.HttpServletResponse.SC_UNAUTHORIZED);
>      return;
>      }
>
>      // call next filter in the chain : let j_security_check authenticate
>      // user
>      chain.doFilter(request, response);
>
>      // post login action
>
>   }
>
> I wouldn't mind seeing a servlet specified as <form-login-page> if you know
> of an example.
>
> -----Original Message-----
> From: Christopher Schultz [mailto:ch...@christopherschultz.net]
> Sent: 05 Oct 2011 22 08
> To: Tomcat Users List
> Subject: Re: Using multiple login pages
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Martin,
>
> On 10/5/2011 1:59 PM, Martin O'Shea wrote:
> > I have it now. There was a redirection going on in a method called
> > from a scriptlet in the login page. It now seems to be OK.
>
> Glad you got it going.
>
> > But one thing bugs me still: you said that you can have 'different
> > login pages for different types of resources you're trying to
> > reach.' Can you give any pointers about this?
>
> A "page" is defined as whatever the server responds when you request a
> resource. The <form-login-page> you configure in your web.xml can be
> dynamic: you can do whatever you want in that page. It doesn't have to
> be a static <form> that always looks the same. You can
> include/forward/etc from that page. It doesn't even have to be a JSP.
> You can configure the <login-form-page> to be a servlet that makes
> decisions and forwards to some other .jsp file.
>
> Use your imagination.
>
> - -chris
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (MingW32)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAk6MxyEACgkQ9CaO5/Lv0PByHACfZL9ykx3wPGApX1yyzjxYwkQR
> Rf4AoJG5DnnBtbIFYzZsKSLzPJOjJq2j
> =A5GW
> -----END PGP SIGNATURE-----
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

Reply via email to