S
Sasha Borodin
Hey All,
I'm looking for advise on how to approach a problem: I would like to use
Container Managed Authentication for a multitude or reasons; however, I need
to be able to perform additional "login" tasks upon authentication.
My first though was to force the "next page" after j_security_check does
it's thing - this way I could point it to an Action that performs my tasks,
and only then honor the originally requested URL. However, this seems not
possible, as the mechanism for forwarding the user to the requested URL is
not part of the Servlet spec, thus proprietary.
My second thought was to "help" j_security_check by either wrapping a filter
around it, or having a session attribute listener catch some distinct
activity produced by the authentication event. I am curious about the
feasibility/side effects of both these approaches. Here's my thoughts so
far:
Filter:
- is it possible to map a filter to just j_security_check...I'd found
something about a problem using a filter with that URI:
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21795
- is it good to separate this part of the code into a filter,
architecturally speaking
Event listener:
- the Pricipal object must be bound to the session I would think; what
would be it's name?
- is this name standard? I did not find any reference to the specifics
in the Servlet spec (will it be different with different containers?)
- would there be a "race" condition (don't know if I'm using the term
correctly) - is it guaranteed that when the Session Attribute event listener
is triggered, it'll be done doing it's thing before the request is passed on
to the requested URL?
-----
Or is there a better way to approach "post-authentication" tasks altogether,
while utilizing Container Managed Authentication? Please don't say
Sourceforge's Security Filter, because I'm trying to stick to CMA and it's
benefits (EJB container authentication for one)
TIA,
-Sasha Borodin
I'm looking for advise on how to approach a problem: I would like to use
Container Managed Authentication for a multitude or reasons; however, I need
to be able to perform additional "login" tasks upon authentication.
My first though was to force the "next page" after j_security_check does
it's thing - this way I could point it to an Action that performs my tasks,
and only then honor the originally requested URL. However, this seems not
possible, as the mechanism for forwarding the user to the requested URL is
not part of the Servlet spec, thus proprietary.
My second thought was to "help" j_security_check by either wrapping a filter
around it, or having a session attribute listener catch some distinct
activity produced by the authentication event. I am curious about the
feasibility/side effects of both these approaches. Here's my thoughts so
far:
Filter:
- is it possible to map a filter to just j_security_check...I'd found
something about a problem using a filter with that URI:
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21795
- is it good to separate this part of the code into a filter,
architecturally speaking
Event listener:
- the Pricipal object must be bound to the session I would think; what
would be it's name?
- is this name standard? I did not find any reference to the specifics
in the Servlet spec (will it be different with different containers?)
- would there be a "race" condition (don't know if I'm using the term
correctly) - is it guaranteed that when the Session Attribute event listener
is triggered, it'll be done doing it's thing before the request is passed on
to the requested URL?
-----
Or is there a better way to approach "post-authentication" tasks altogether,
while utilizing Container Managed Authentication? Please don't say
Sourceforge's Security Filter, because I'm trying to stick to CMA and it's
benefits (EJB container authentication for one)
TIA,
-Sasha Borodin