tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sasha Borodin <sa...@whoissasha.com>
Subject Re: extend j_security_check - filter or event listener?
Date Mon, 28 Jul 2003 14:15:56 GMT
That's what I'm thinking about implementing.  But I'm trying to avoid the
overhead of the filter's conditional logic being processed on EVERY request
(seems like a lot of unnecessary overhead).

Any comments on the feasibility of filtering just the j_security_check URI,
or listening for the Principal being bound to the session (if that is indeed
where it is stored upon CMA)?

TIA,

-Sasha Borodin

On 7/27/03 18:32, "Craig Berry" <Craig.Berry@portblue.com> wrote:

> I handled this situation by having logged-in users have a UserModel object in
> the session.  In a filter that catches all servlet requests, I check if
> request.getAuthenticatedUser returns non-null and there is no UserModel obj in
> the session.  If this occurs, I know that a new user just logged in, and do
> login processing including creating and session-storing their UserModel.  Part
> of logout processing is invalidating the session, so the UM object goes away.
> 
> -----Original Message-----
> From: Sasha Borodin [mailto:sasha@whoissasha.com]
> Sent: Sun 7/27/2003 3:54 PM
> To: tomcat-user@jakarta.apache.org
> Cc: 
> Subject: extend j_security_check - filter or event listener?
> 
> 
> 
> 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
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
> 
> 
> 


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


Mime
View raw message