myfaces-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Richard Wallace <rwall...@thewallacepack.net>
Subject Re: Acegi and JSF integration
Date Tue, 05 Jul 2005 22:38:11 GMT
I've done much the same, implemented a backing bean that handles 
authentication.  I took the AuthenticationProcessingFilter out of the 
FilterChainProxy.  I've got authentication working just fine now, the 
only thing left that I have to figure out is if there was a restricted 
URL that was requested and caused the user to be redirected to the login 
page, how to redirect to that originally requested url rather than let 
the JSF navigation rule that handles successful authentication redirect 
to the main post-login page.  Any suggestions?

Thanks,
Rich

Victor Tatai wrote:

>Hello Richard and Enrique,
>
>I have detailed yet another approach for integranting JSF and Acegi in my blog:
>
>http://www.jroller.com/page/vtatai/20050505#integrating_acegi_with_jsf
>
>Regards,
>
>Victor
>
>On 7/1/05, Enrique Medina <e.medina.m@gmail.com> wrote:
>  
>
>>Hi Richard,
>>
>>I'm currently using Acegi and JSF together and I found a feasible
>>solution (at least to me) to solve the gap between them.
>>
>>The main problem comes from the fact that Acegi uses a filter to do
>>the security stuff, and also Acegi expects some information from the
>>request, that cannot be given by JSF without some modifications (or
>>maybe some hacks).
>>
>>The first problem comes with Acegi expecting a specific parameter name
>>for the user and password in the form. As JSF generates the IDs for
>>the form elements, you will have to use MyFaces "forceId" property in
>>order to ensure that the expected IDs arrive to the Acegi filter.
>>
>>Regarding the filter, I also had to extend it in order to provide
>>extra functionality so as to be able to check not only the user and
>>the password, but also some other parameters (like the IP used to
>>connect to the web site).
>>
>>So, if you use the "forceId" attribute, and then use a "commandButton"
>>with an action in one of your JSF beans, what will happen?:
>>
>>1) The JSF page gets rendered within the JSF context.
>>2) Expected IDs are given to the form elements (user & password, for example)
>>3) When the login information is entered, a new request is created and
>>the Acegi filter catches it
>>4) The Acegi filter tries to take from the request parameter map all
>>the expected information, and it can, due to the fact of using
>>"forceId"
>>5) Acegi executes its stuff without knowing it is in a JSF context and:
>>    5.1) If Acegi can validate the user, then it will redirect the
>>request, not to the JSF bean specified in the form, but to the home
>>page specified in the Spring's application context XML file (see Acegi
>>declarative configuration),
>>    5.2) If Acegi cannot validate the user, then here comes a little
>>hack. We have to make Acegi return the flow to the JSF context, in
>>particular to the JSF bean action method specified for the web form.
>>What I've done is to save the Acegi exception in the session, then
>>just continue the filter chain, and when the flow arrives to my JSF
>>action method, take the exception from the session, compose a JSF
>>error message, and return a NULL from the action method in order to
>>stay in the same page. So the final result is that the login page gets
>>redrawn, and an error message appears to the user (using h:message
>>tag).
>>
>>I hope this can help you.
>>
>>Regards.
>>
>>2005/7/1, Richard Wallace <rwallace@thewallacepack.net>:
>>    
>>
>>>Hey everyone,
>>>
>>>I'm progressing with our move to Java and JSF and am trying to integrate
>>>some security.  I've decided on using Acegi Security because I need to
>>>be able to have domain object level ACLs and it's the most complete open
>>>source implementation I've seen.  But, I'm having some problems figuring
>>>how best to integrate it with JSF.
>>>
>>>The main issue is that most of the servlet security stuff is implemented
>>>in Servlet Filters, including the part that authenticates the user.
>>>Whats worse, IMO, is that the Filters are actually Spring managed beans
>>>proxied by a delegating Filter.  The main problems I have with this is
>>>that I can't create a nice JSF form with an
>>>action="#{authHandler.authenticate}" action handler.  I'd also like to
>>>control the flow of the page and what happens when logins succeed/fail
>>>from the JSF navigation.  As it stands now that's actually handled by
>>>one of the Spring managed beans.
>>>
>>>To these ends I've created an AuthenticationHandler backing bean, mostly
>>>just copying the code in the AuthenticationProcessingFilter class which
>>>listens for requests to a certain URL and tries to login the user with
>>>the credentials in the request.  The other stuff is a bit more
>>>complicated and I'm not 100% sure where to begin.  I'm thinking I need
>>>to create PhaseListener classes for the other Filters and copying the
>>>code from the corresponding filters.
>>>
>>>Has anyone worked on integrating Acegi  and JSF more seemlessly before?
>>>I'd appreciate any advice anyone can give.
>>>
>>>Thanks,
>>>Rich
>>>
>>>      
>>>
>
>
>  
>


Mime
View raw message