You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by David Delbecq <de...@oma.be> on 2007/08/20 11:20:27 UTC
How to detect user logins
Hello,
I'm in a situation where i need some operations to be done upon user
login. The idea is, when a user access a secured area, it get's first
promped for http auth (security constraint, that part is working without
trouble), but when the user get authenticated, before giving user his
request result, request should be handled by a filter or alike that will
do various operations (like profile upgrade to new version in database,
eventually displaying an upgrade page for mandatory informations).
For now, the layout is
Filter that check userPrincipal. If user principal is not null for the
first time, issues that check, mark that user got checked for next
times, in session, and continue query.
However, if i could mark the session as "need upgrade" upon login, this
would make things, i think, easier to manage as filter would only need
to look for that "need upgrade" flag.
--
http://www.noooxml.org/
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: How to detect user logins
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
David,
David Delbecq wrote:
> Current strategy works (it's separated in 2 steps inside a common-chain
> of operation), but it makes wuite a few lines to try to detect user
> login, and if tomcat was already providing such event that could be
> handled by a context listener, that would have been, perhaps, cleaner.
How about an HttpSessionListener? It looks like what you really want is
a LoginListener or something like that, which doesn't exist in the spec.
You could always write your own Realm by subclassing an existing one and
adding such notification (or even stuff your magic "needs-upgrade"
object into the session.
I still don't think you'll be saving yourself that much work. Null
checks are cheap, and since they can be deployed on any app server and
any version (good luck when you upgrade Tomcat if you're subclasses the
Realm), I would recommend the more manageable solution over the
(potentially) faster one.
- -chris
>
> En l'instant précis du 20/08/07 17:41, Christopher Schultz s'exprimait
> en ces termes:
>> David,
>>
>> David Delbecq wrote:
>>> For now, the layout is Filter that check userPrincipal. If user
>>> principal is not null for the first time, issues that check, mark
>>> that user got checked for next times, in session, and continue query.
>>> However, if i could mark the session as "need upgrade" upon login,
>>> this would make things, i think, easier to manage as filter would
>>> only need to look for that "need upgrade" flag.
>> I think you'll find that you're just breaking your filter into two
>> separate filters: you'd have one that check to see if the session "needs
>> an upgrade", and then another one to "upgrade" it. Since the
>> functionality is all related, I'm not sure if there's a good reason not
>> to keep it all together.
>>
>> Do you have any particular complaints about your existing strategy?
>>
>> -chris
>>
>
> ---------------------------------------------------------------------
> To start a new topic, e-mail: users@tomcat.apache.org
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFGyuqF9CaO5/Lv0PARAvxHAJ0XQpmTm1mnS40M3E00n2izln9jWwCeIri/
dHKr3EGCZ5HxIs8whMb+LJ4=
=nrd+
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: How to detect user logins
Posted by David Delbecq <de...@oma.be>.
Current strategy works (it's separated in 2 steps inside a common-chain
of operation), but it makes wuite a few lines to try to detect user
login, and if tomcat was already providing such event that could be
handled by a context listener, that would have been, perhaps, cleaner.
En l'instant précis du 20/08/07 17:41, Christopher Schultz s'exprimait
en ces termes:
> David,
>
> David Delbecq wrote:
> > For now, the layout is Filter that check userPrincipal. If user
> > principal is not null for the first time, issues that check, mark
> > that user got checked for next times, in session, and continue query.
> > However, if i could mark the session as "need upgrade" upon login,
> > this would make things, i think, easier to manage as filter would
> > only need to look for that "need upgrade" flag.
>
> I think you'll find that you're just breaking your filter into two
> separate filters: you'd have one that check to see if the session "needs
> an upgrade", and then another one to "upgrade" it. Since the
> functionality is all related, I'm not sure if there's a good reason not
> to keep it all together.
>
> Do you have any particular complaints about your existing strategy?
>
> -chris
>
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
--
David Delbecq
Institut Royal Météorologique
Ext:518
--
http://www.noooxml.org/
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: How to detect user logins
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
David,
David Delbecq wrote:
> For now, the layout is Filter that check userPrincipal. If user
> principal is not null for the first time, issues that check, mark
> that user got checked for next times, in session, and continue query.
> However, if i could mark the session as "need upgrade" upon login,
> this would make things, i think, easier to manage as filter would
> only need to look for that "need upgrade" flag.
I think you'll find that you're just breaking your filter into two
separate filters: you'd have one that check to see if the session "needs
an upgrade", and then another one to "upgrade" it. Since the
functionality is all related, I'm not sure if there's a good reason not
to keep it all together.
Do you have any particular complaints about your existing strategy?
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFGybYb9CaO5/Lv0PARAvhKAJ98z4exrOeiSHS+0eQ2IlYWYl17lACeK5mF
JKrxaBpWuU+0DsXoST1jKbU=
=ByA4
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org