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.
Regards
Ingo
