myfaces-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ingo Düppe <>
Subject Re: managed-beans, spring references, and serializable
Date Tue, 26 Sep 2006 08:30:35 GMT
Craig McClanahan schrieb:
> In general, security frameworks that try to mimic container managed 
> security only do their checks on the initial request URI, not on 
> RequestDispatcher.forward() calls.  A couple of approaches to consider:
> * If you are running on a Servlet 2.4 or later container,
>   you can configure the filter to run on forwards as well
>   as the initial request.  I don't know if AcegiSecurity is
>   set up to work in this manner, but it's worth a try.
> * Conceptually, it sounds like you are trying to apply
>   access control on the destination of a navigation rule.
>   One way to implement this might be to do a custom
>   NavigationHandler that delegates to the standard one,
>   then examines the new viewId and sees if it is acceptable
>   for this user.
>     My question now is, are there any experience to integrate these
>     frameworks with shale?
> I know Spring works fine with Shale.  I've heard scattered reports of 
> problems with Facelets, and that's high on my list of things to 
> evaluate.  I haven't tried AcegiSecurity yet, but there's nothing in 
> Shale that should make it work any differently than it does with 
> MyFaces directly.
> Lastly, now that MyFaces 1.1.4 is out, we will be testing and updating 
> the dependency (for the nightly builds of Shale) to use 1.1.4 instead 
> of 1.1.1 --- so that will get a lot of attention.  (Shale doesn't care 
> what component library you use, so Tomahawk shouldn't be an issue 
> unless it does wierd things with some of the JSF extension points.)
>     Regards.
>     Ingo
> Craig
Hello Craig,

thank you for the detailed answer. I'm already on the way integrating 
shale :-).

I configured acegisecurity filter to listen on servlet forwards. But the 
problem came from facelets, as soon I integrated facelets there were no 
more forwards during the lifecycle :-(, so the security filter is not 
informed about view changes. So I also decided to write a custom 
navigation handler, but within the navigation handler you only have the 
information about the current viewId and the outcome that was generated, 
but nothing about the next viewId. Because that is the duty of the 
navigation handler. And unfortunately  there is  no  specification api  
to figure out  the next viewId and I didn't like to make a hardcoded 
dependency to myfaces implementation to figure out that next viewId. So 
I decided to implement a PhaseListener that backup the incoming viewId 
in the early phases and if this viewId changed before the 
render-response phase it make a redirect to the new viewId.


View raw message