Sep 22nd, 2006, 04:30 AM
Attempting a login page for Acegi using a JSF backing bean
Hi, I'm quite new to Acegi but I have gone through the suggested steps and did manage to successfully secure the pages for my web applications using with configuration derived mostly from the samples.
My problem now is that I need to convert the login page into a JSF page, due to some design requirement and some underlying architecture.
I would say that documentation on using alternative login methods for Acegi is quite lacking, but I managed to find:
And 2 other blog posts talking about the same thing; that is, to use an actual backing bean to perform manual authentication rather than relying on Acegi's filters.
I have attempted to implement something like that for my own web app but I probably missed something. Now my filterSecurityInterceptor doesn't work anymore and every single page is exposed. The Authentication object seems to disappear in separate requests. Not sure if the post above left something out cos I even tried copying everything exactly.
I would really really appreciate it if someone could take some time to help me break down the necessary steps to move acegi form authentication to backing bean authentication. At least enough so I can start understanding things better.
Thanks for reading. All help appreciated.
Sep 22nd, 2006, 08:39 AM
i moved with the blog to http://www.javakaffee.de/blog/, the posting you find now at http://www.javakaffee.de/blog/2006/0...-backing-bean/.
What might have been missing is the objectDefinitionSource IS_AUTHENTICATED_FULLY, i added this afterwards as i also found that it was missing.
Can you compare what you have with the one of http://www.javakaffee.de/blog/2006/0...backing-bean/?
This is working for me, so we should manage to get it working for you also
Sep 25th, 2006, 09:02 PM
Hmm... after a couple more tweaks I seem to have gotten the filter invocation back working again. Except now firefox is complaining that I have an infinite redirection problem. Funny that I only redirect to login and that page doesn't go anywhere else. But at least all the other pages are trying to forward to login now...
Also, "scope" is not an attribute to the "bean" tag in spring's app context. How did you manage to do that?
EDIT: Never mind about the redirect problem. I accidentally left in an anonymous pattern that kinda redirected the login back to the login because I've already removed the anonymous filter :P
Last edited by aberrant80; Sep 25th, 2006 at 09:52 PM.
Sep 26th, 2006, 01:45 AM
Sorry if i forgot to mention that i'm using spring2. This is really cool because it introduces new scopes as session or request... This is very useful for integration with JSF and other webframeworks...
Sep 28th, 2006, 09:28 PM
Is this still possible without using Spring2? Do I have to manually maintain the AuthenticationController at session scope level?
I think I'm not getting something still. Right now, on logout(), SecurityContextHolder.getContext().getAuthenticati on() already returns a null. Is that expected because Acegi already destroyed the Authentication object prior to control reaching logout()? So unless I keep my own session data, I can't actually retrieve the principal from the SecurityContext inside logout() then...
Last edited by aberrant80; Sep 28th, 2006 at 10:04 PM.
Sep 29th, 2006, 03:51 AM
You should be able to maintain session/request scoped beans with JSF, so define them in the faces-config.xml as managed-beans and inject required properties via the managed-properties mechanism. You should be able to use value expressions that reference spring managed beans when you have configured the DelegatingVariableResolver.
We simply put all beans into the spring configuration file to have a single place where beans are defined...
Feb 12th, 2007, 12:03 PM
Last edited by jiai; Feb 13th, 2007 at 01:56 AM.
Feb 13th, 2007, 09:44 AM
After some more reading in this forum (i.e. http://forum.springframework.org/showthread.php?t=27578), I found out that adding <redirect/> to the navigation case seems to do the job - authorization works now for navigation with JSF.
But I haven't tested what happens if there are parameters within the post - are they possibly evaluated without authorization?
Nevertheless this seems to me as a brittle and awkward solution - isn't there a better, cleaner, Acegi worthly solution with a working filter chain for JSF?
Playing around with acegi-jsf http://www.jroller.com/page/cagatayc...onents_hit_the , the advice to define the "SecurityContextHolderAwareRequestFilter" in the Acegi filter chain was the key to get this taglib (JSF1.2, acegi-jsf v-1-1-2) working.
As a novice user of Spring/Acegi it seems to me, that the out of the box support of JSF from the core Acegi is a bit dissapointing.
Feb 14th, 2007, 12:42 PM
Stuck, tired, and hungry
There is a really bad side effect with this redirect solution: It works only if cookies are enabled! I didn't found a solution to encodeURI for the navigation rule, because it's stored in a static XML file.
Originally Posted by jiai
There was an article for Webflow which recommends the redirect solution for their framework (http://www.ervacon.com/products/swf/tips/tip4.html) - unfortunately JSF 1.2 seems to be not supported.
So now it's time for me to say: I'm stuck, tired, and hungry ...
Feb 15th, 2007, 01:24 PM
A short remark on this: This behavior is a bug in JSF1.2_02, according to http://forums.java.net/jive/thread.j...23149&tstart=0. This bug is solved in JSF 1.2_03. Unfortunately Netbeans VisualWeb has a bug in its webuijsf taglibrary which prevents me from upgrading the JSF version. As a workaround I'll enable cookies during development.
Originally Posted by jiai