tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Schultz <ch...@christopherschultz.net>
Subject Re: Detecting a login or logoff event
Date Thu, 06 Oct 2011 18:49:54 GMT
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Martin,

On 10/6/2011 9:29 AM, Martin O'Shea wrote:
> 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

That sounds like a fragile way to do it: you have to make sure that
all JSPs have the same scriptlet, use it properly, have error
recovery, etc.

> but is a filter better?

Absolutely: this is the kind of thing that Filters were created for.

> But if so, what might a filter check for?

That depends. If you are using FORM authentication, then this stuff is
possible. If you use HTTP BASIC/DIGEST or CLIENT-CERT, things get
complicated.

Let's assume FORM. It's simple: in your Filter, check to see if the
user is logged-in (request.getPrincipal) but there is no
"loggedIntoSession" token in the session. If that's the case, perform
your login procedure and then write your "loggedIntoSession" token
into the session.

As others have suggested, for logout you'll have to use a
HttpSessionListener. If the user was logged-in, you can get their
loggedIntoSession token (which ought to include some identifier for
them) and do whatever you want. No need to remove the
"loggedInotSession" token, since the session will be destroyed anyway.

We use this exact same technique to do things like update the
last-logged-in date of the user, as well as loading user-specific
preferences from the database into the session. The entire Filter
class, including blank lines, imports, comments, and specialized
methods to build the preferences objects to store in the session is a
mere 336 lines of code. This is something that is not terribly complex
to handle.

- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk6N+FIACgkQ9CaO5/Lv0PB+nwCfR3AMFmDy3vejPIBT0IREapjA
wb4AmwZ7GOJ51pVDBrnG1m7E7x2xZhit
=NXi/
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Mime
View raw message