Announcement Announcement Module
Collapse
No announcement yet.
Attempting a login page for Acegi using a JSF backing bean Page Title Module
Move Remove Collapse
This topic is closed
X
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • 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:

    http://magrokosmos.blogspot.com/2006...h-backing.html

    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.

  • #2
    Hi,

    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

    Cheers,
    Martin

    Comment


    • #3
      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, 10:52 PM. Reason: resolved

      Comment


      • #4
        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...

        Comment


        • #5
          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, 11:04 PM.

          Comment


          • #6
            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...

            Comment


            • #7
              Originally posted by martin.grotzke View Post
              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/.
              Thanks to your work, I got it run so far.

              But there is another issue: If someone - like me - uses the Creator2/NetbeansVisualWeb programming model, that means not Facelets, she would run into the next problem. Securing on different levels (e.g. secure/extremeSecure) seems to be impossible with Acegi and JSF.
              Whilst access for unauthenticated users is prohibited as expected, it seems to me that authenticated/authorized users for "secure" have access to "extremeSecure", even if they are not in the appropriate role.

              Did I made a mistake in the filter chain or is it a general problem with JSF and Acegi? There are some articles in this forum which imply the latter.

              If it is not an Acegi problem - can somebody please post a working chain for JSF (Creator/NetbeansVisualWeb model) which handles such an escalation of security grades?

              jiai
              Last edited by jiai; Feb 13th, 2007, 02:56 AM.

              Comment


              • #8
                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.

                Greetings,
                jiai

                Comment


                • #9
                  Stuck, tired, and hungry

                  Originally posted by jiai View Post
                  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.
                  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.
                  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 ...

                  Greetings,
                  jiai

                  Comment


                  • #10
                    Originally posted by jiai View Post
                    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.
                    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.

                    Greetings,
                    jiai

                    Comment

                    Working...
                    X