Announcement Announcement Module
Collapse
No announcement yet.
Acegi login failure: redirect gets lost in Websphere v6.1 Page Title Module
Move Remove Collapse
This topic is closed
X
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • Acegi login failure: redirect gets lost in Websphere v6.1

    Hi,

    I still have problems getting Acegi to work as it should in Websphere v6.1 (despite all 'fixes' described here, here and here, which I have applied but only partially improve the situation ).

    I use a 'standard' acegi setup, with a sequence of usernamepassword authentication, anonymous authentication and rememberme authentication. The applicationcontext-security.xml of my app is attached to this post.

    For the logout I wrote my own Spring controller, doing a session invalidate, a removal of the rememberme cookie and an acegi clearcontext, since the redirect when using /j_acegi_logout in Websphere v6.1 gets lost somewhere.

    However, for the login part I would like to keep the setup as I have it now, I don't want to write my own login controller doing the same steps as Acegi already does, simply because Websphere is swallowing the redirects when issued from within a servlet-filter.

    Logging in goes fine (i.e. the context is filled correctly, and the redirect goes to the page saved under the ACEGI_SAVED_REQUEST_KEY key) as long as you don't type anything wrong. However, when you throw an exception during login, Acegi should redirect either to a .jsp specified in the exceptionMappings list, either to the 'default' authenticationFailureUrl. And this is were things go wrong in Websphere v6.1. It will perform a cookie cancel, a clearcontext and session invalidate, but then it looses the redirect sent from within the org.acegisecurity.ui.AbstractProcessingFilter, and retries redirecting again to the /j_acegi_security_check URL (for the second time thus, ending in a blank html page displayed to the user), and I have no clue where this is happening, since the URL I specified in the redirect is /login.jsp?login_error=1.

    Attached is as well the logging for the same sequence of events -mistyping a username duing login- in Tomcat5.5 (which works fine) and Websphere v6.1.
    The empty line in the logfiles is where things start to go wrong in Websphere v6.1.

    Did anyone manage to get redirects working fine when throwing acegi AuthenticationExceptions in WASv6.1? Ah, and yes: I'm already running the latest WASv6.1.0.9 FP. It seems that quite some things get broken with each new release of Websphere, even if those worked fine on previous releases. I've been using the SpringFramework on WASv5.1, WASv6.0 and now on WASv6.1, and with each new release things seem to be worse.

    Not meaning to be rude, but I wonder what the certification means?

  • #2
    Fixed!

    Just for anyone who wants to know: this issue got fixed in FixPack 6.1.0.11, which was released earlier this week.

    Comment


    • #3
      Is it really fixed?

      Originally posted by wpraet View Post
      Just for anyone who wants to know: this issue got fixed in FixPack 6.1.0.11, which was released earlier this week.
      Hi!

      Is it!?

      I get "HTTP 404 Not Found" on a brand new 6.1.0.11 install


      Acegi log:
      Code:
      [2007-10-18 11:18:07,839] DEBUG org.acegisecurity.context.HttpSessionContextIntegrationFilter New SecurityContext instance will be associated with SecurityContextHolder 
      [2007-10-18 11:18:07,849] DEBUG org.acegisecurity.util.FilterChainProxy / at position 2 of 6 in additional filter chain; firing Filter: '[email protected]16' 
      [2007-10-18 11:18:07,849] DEBUG org.acegisecurity.util.FilterChainProxy / at position 3 of 6 in additional filter chain; firing Filter: '[email protected]3c' 
      [2007-10-18 11:18:07,849] DEBUG org.acegisecurity.util.FilterChainProxy / at position 4 of 6 in additional filter chain; firing Filter: '[email protected]ae24ae2' 
      [2007-10-18 11:18:07,849] DEBUG org.acegisecurity.providers.anonymous.AnonymousProcessingFilter Populated SecurityContextHolder with anonymous token: 'org.acegisecurity.providers.anonymous.AnonymousAuthenticationToken@52a3eba1: Username: anonymous; Password: [PROTECTED]; Authenticated: true; Details: org.acegisecurity.ui.WebAuthenticationDetails@3bcc: RemoteIpAddress: 193.10.23.36; SessionId: null; Granted Authorities: ROLE_ANONYMOUS' 
      [2007-10-18 11:18:07,849] DEBUG org.acegisecurity.util.FilterChainProxy / at position 5 of 6 in additional filter chain; firing Filter: 'org.acegisecurity.ui.ExceptionTranslationFilter@7700770' 
      [2007-10-18 11:18:07,849] DEBUG org.acegisecurity.util.FilterChainProxy / at position 6 of 6 in additional filter chain; firing Filter: '[email protected]4' 
      [2007-10-18 11:18:07,849] DEBUG org.acegisecurity.intercept.web.PathBasedFilterInvocationDefinitionMap Converted URL to lowercase, from: '/'; to: '/' 
      [2007-10-18 11:18:07,849] DEBUG org.acegisecurity.intercept.web.PathBasedFilterInvocationDefinitionMap Candidate is: '/'; pattern is /secret/*; matched=false 
      [2007-10-18 11:18:07,849] DEBUG org.acegisecurity.intercept.web.PathBasedFilterInvocationDefinitionMap Candidate is: '/'; pattern is /login.do; matched=false 
      [2007-10-18 11:18:07,849] DEBUG org.acegisecurity.intercept.web.PathBasedFilterInvocationDefinitionMap Candidate is: '/'; pattern is /pics/*; matched=false 
      [2007-10-18 11:18:07,849] DEBUG org.acegisecurity.intercept.web.PathBasedFilterInvocationDefinitionMap Candidate is: '/'; pattern is /theme/*; matched=false 
      [2007-10-18 11:18:07,849] DEBUG org.acegisecurity.intercept.web.PathBasedFilterInvocationDefinitionMap Candidate is: '/'; pattern is /service/dump.do*; matched=false 
      [2007-10-18 11:18:07,849] DEBUG org.acegisecurity.intercept.web.PathBasedFilterInvocationDefinitionMap Candidate is: '/'; pattern is /**; matched=true 
      [2007-10-18 11:18:07,849] DEBUG org.acegisecurity.intercept.AbstractSecurityInterceptor Secure object: FilterInvocation: URL: /; ConfigAttributes: [ROLE_ANONYMOUS, ROLE_STUDY] 
      [2007-10-18 11:18:07,849] DEBUG org.acegisecurity.intercept.AbstractSecurityInterceptor Previously Authenticated: org.acegisecurity.providers.anonymous.AnonymousAuthenticationToken@52a3eba1: Username: anonymous; Password: [PROTECTED]; Authenticated: true; Details: org.acegisecurity.ui.WebAuthenticationDetails@3bcc: RemoteIpAddress: 193.10.23.36; SessionId: null; Granted Authorities: ROLE_ANONYMOUS 
      [2007-10-18 11:18:07,849] DEBUG org.acegisecurity.intercept.AbstractSecurityInterceptor Authorization successful 
      [2007-10-18 11:18:07,849] DEBUG org.acegisecurity.intercept.AbstractSecurityInterceptor RunAsManager did not change Authentication object 
      [2007-10-18 11:18:07,849] DEBUG org.acegisecurity.util.FilterChainProxy / reached end of additional filter chain; proceeding with original chain 
      [2007-10-18 11:18:08,310] DEBUG org.acegisecurity.context.HttpSessionContextIntegrationFilter SecurityContext stored to HttpSession: 'org.acegisecurity.context.SecurityContextImpl@52a3eba1: Authentication: org.acegisecurity.providers.anonymous.AnonymousAuthenticationToken@52a3eba1: Username: anonymous; Password: [PROTECTED]; Authenticated: true; Details: org.acegisecurity.ui.WebAuthenticationDetails@3bcc: RemoteIpAddress: 193.10.23.36; SessionId: null; Granted Authorities: ROLE_ANONYMOUS' 
      [2007-10-18 11:18:08,310] DEBUG org.acegisecurity.ui.ExceptionTranslationFilter Chain processed normally 
      [2007-10-18 11:18:08,310] DEBUG org.acegisecurity.context.HttpSessionContextIntegrationFilter SecurityContextHolder now cleared, as request processing completed 
      [2007-10-18 11:18:08,330] DEBUG org.acegisecurity.intercept.web.PathBasedFilterInvocationDefinitionMap Converted URL to lowercase, from: '/login.do'; to: '/login.do' 
      [2007-10-18 11:18:08,330] DEBUG org.acegisecurity.intercept.web.PathBasedFilterInvocationDefinitionMap Candidate is: '/login.do'; pattern is /**; matched=true 
      [2007-10-18 11:18:08,330] DEBUG org.acegisecurity.util.FilterChainProxy /login.do at position 1 of 6 in additional filter chain; firing Filter: '[email protected]08d4' 
      [2007-10-18 11:18:08,330] DEBUG org.acegisecurity.context.HttpSessionContextIntegrationFilter Obtained a valid SecurityContext from ACEGI_SECURITY_CONTEXT to associate with SecurityContextHolder: 'org.acegisecurity.context.SecurityContextImpl@52a3eba1: Authentication: org.acegisecurity.providers.anonymous.AnonymousAuthenticationToken@52a3eba1: Username: anonymous; Password: [PROTECTED]; Authenticated: true; Details: org.acegisecurity.ui.WebAuthenticationDetails@3bcc: RemoteIpAddress: 193.10.23.36; SessionId: null; Granted Authorities: ROLE_ANONYMOUS' 
      [2007-10-18 11:18:08,330] DEBUG org.acegisecurity.util.FilterChainProxy /login.do at position 2 of 6 in additional filter chain; firing Filter: '[email protected]16' 
      [2007-10-18 11:18:08,330] DEBUG org.acegisecurity.util.FilterChainProxy /login.do at position 3 of 6 in additional filter chain; firing Filter: '[email protected]3c' 
      [2007-10-18 11:18:08,330] DEBUG org.acegisecurity.ui.rememberme.RememberMeProcessingFilter SecurityContextHolder not populated with remember-me token, as it already contained: 'org.acegisecurity.providers.anonymous.AnonymousAuthenticationToken@52a3eba1: Username: anonymous; Password: [PROTECTED]; Authenticated: true; Details: org.acegisecurity.ui.WebAuthenticationDetails@3bcc: RemoteIpAddress: 193.10.23.36; SessionId: null; Granted Authorities: ROLE_ANONYMOUS' 
      [2007-10-18 11:18:08,330] DEBUG org.acegisecurity.util.FilterChainProxy /login.do at position 4 of 6 in additional filter chain; firing Filter: '[email protected]ae24ae2' 
      [2007-10-18 11:18:08,330] DEBUG org.acegisecurity.providers.anonymous.AnonymousProcessingFilter SecurityContextHolder not populated with anonymous token, as it already contained: 'org.acegisecurity.providers.anonymous.AnonymousAuthenticationToken@52a3eba1: Username: anonymous; Password: [PROTECTED]; Authenticated: true; Details: org.acegisecurity.ui.WebAuthenticationDetails@3bcc: RemoteIpAddress: 193.10.23.36; SessionId: null; Granted Authorities: ROLE_ANONYMOUS' 
      [2007-10-18 11:18:08,330] DEBUG org.acegisecurity.util.FilterChainProxy /login.do at position 5 of 6 in additional filter chain; firing Filter: 'org.acegisecurity.ui.ExceptionTranslationFilter@7700770' 
      [2007-10-18 11:18:08,330] DEBUG org.acegisecurity.util.FilterChainProxy /login.do at position 6 of 6 in additional filter chain; firing Filter: '[email protected]4' 
      [2007-10-18 11:18:08,330] DEBUG org.acegisecurity.intercept.web.PathBasedFilterInvocationDefinitionMap Converted URL to lowercase, from: '/login.do'; to: '/login.do' 
      [2007-10-18 11:18:08,330] DEBUG org.acegisecurity.intercept.web.PathBasedFilterInvocationDefinitionMap Candidate is: '/login.do'; pattern is /secret/*; matched=false 
      [2007-10-18 11:18:08,330] DEBUG org.acegisecurity.intercept.web.PathBasedFilterInvocationDefinitionMap Candidate is: '/login.do'; pattern is /login.do; matched=true 
      [2007-10-18 11:18:08,330] DEBUG org.acegisecurity.intercept.AbstractSecurityInterceptor Secure object: FilterInvocation: URL: /login.do; ConfigAttributes: [ROLE_ANONYMOUS] 
      [2007-10-18 11:18:08,330] DEBUG org.acegisecurity.intercept.AbstractSecurityInterceptor Previously Authenticated: org.acegisecurity.providers.anonymous.AnonymousAuthenticationToken@52a3eba1: Username: anonymous; Password: [PROTECTED]; Authenticated: true; Details: org.acegisecurity.ui.WebAuthenticationDetails@3bcc: RemoteIpAddress: 193.10.23.36; SessionId: null; Granted Authorities: ROLE_ANONYMOUS 
      [2007-10-18 11:18:08,330] DEBUG org.acegisecurity.intercept.AbstractSecurityInterceptor Authorization successful 
      [2007-10-18 11:18:08,330] DEBUG org.acegisecurity.intercept.AbstractSecurityInterceptor RunAsManager did not change Authentication object 
      [2007-10-18 11:18:08,330] DEBUG org.acegisecurity.util.FilterChainProxy /login.do reached end of additional filter chain; proceeding with original chain 
      [2007-10-18 11:18:08,340] DEBUG org.ki.biobank.elsa.web.MultiactionController Show login invoked 
      [2007-10-18 11:18:08,490] DEBUG org.acegisecurity.ui.ExceptionTranslationFilter Chain processed normally 
      [2007-10-18 11:18:08,490] DEBUG org.acegisecurity.context.HttpSessionContextIntegrationFilter SecurityContextHolder now cleared, as request processing completed

      Very grateful for nay ideas at all.....

      Comment


      • #4
        Hi there,

        did you set the
        Code:
        com.ibm.ws.webcontainer.invokefilterscompatibility
        property in the webcontainer to 'true'?

        Comment


        • #5
          Yes, I did. Still no cigar.

          Originally posted by wpraet View Post
          Hi,
          Not meaning to be rude, but I wonder what the certification means?
          Your're not beeing rude, I think it's a very reasonable question......
          Last edited by kantorn; Oct 18th, 2007, 08:03 AM.

          Comment


          • #6
            Seems like I have to ditch Spring Security.
            Very sad.

            Comment


            • #7
              Not meaning to be rude, but I wonder what the certification means?
              Spring FRAMEWORK is certified for Websphere not ACEGI Security, don't mix things up.

              Also you might have some problems in your setup.

              Why do you process jsp by acegi? it can be very well that requests to *.jsp get cut off before even being processed.

              Also making your jsp's publicly available isn't wise, I would put them in /WEB-INF/jsp and configure everything to pass through the dispatcher servlet (i.e. *.do etc). Use a ViewResolver to retrieve the correct jsp.

              Also I'm not sure if you need to or if it is wise to include the acegi urls in your security or even ommit certain filters from those chains!

              In your configuration

              Code:
              <property name="authenticationFailureUrl" value="login.jsp?login_error=1"/>
              <property name="useRelativeContext" value="true"/>
              You use a relative path you might want to try an absolute path, else it might get appended to /j_acegi_security_check or something, which could also screw up things.

              Just a few thoughts at first glance at your configuration.

              Comment


              • #8
                Originally posted by mdeinum View Post
                Spring FRAMEWORK is certified for Websphere not ACEGI Security, don't mix things up.

                Also you might have some problems in your setup.

                Why do you process jsp by acegi? it can be very well that requests to *.jsp get cut off before even being processed.

                Also making your jsp's publicly available isn't wise, I would put them in /WEB-INF/jsp and configure everything to pass through the dispatcher servlet (i.e. *.do etc). Use a ViewResolver to retrieve the correct jsp.

                Also I'm not sure if you need to or if it is wise to include the acegi urls in your security or even ommit certain filters from those chains!

                In your configuration

                Code:
                <property name="authenticationFailureUrl" value="login.jsp?login_error=1"/>
                <property name="useRelativeContext" value="true"/>
                You use a relative path you might want to try an absolute path, else it might get appended to /j_acegi_security_check or something, which could also screw up things.

                Just a few thoughts at first glance at your configuration.
                Thanks for answering.

                I have my JSPs in WEB-INF/jsp, and they are dispatched using a ViewResolver.

                No, the relative/not relative approach doesn't make things better.

                Also I'm not sure if you need to or if it is wise to include the acegi urls in your security or even ommit certain filters from those chains!
                I don't quite understand, could you clarify by an example?

                Thanks!

                Comment


                • #9
                  Originally posted by kantorn View Post
                  Seems like I have to ditch Spring Security.
                  Very sad.
                  Can't you ditch websphere instead .

                  Comment


                  • #10
                    Originally posted by Luke View Post
                    Can't you ditch websphere instead .
                    Believe me; if I could I would!!!



                    I mean, what is with these products not adhering to the most basic of Java EE specs!? And still people pay for it, a lot!

                    Can I implement a controller of my own simulationg the behaviour of the login filter?
                    Last edited by kantorn; Oct 18th, 2007, 12:26 PM.

                    Comment


                    • #11
                      Originally posted by kantorn View Post
                      Believe me; if I could I would!!!



                      I mean, what is with these products not adhering to the most basic of Java EE specs!? And still people pay for it, a lot!

                      Can I implement a controller of my own simulationg the behaviour of the login filter?
                      Hi, we are also using WebSphere 6.1.0.11 (without the Web Services Feature Pack) and we have the same problem. Is it possible to create a workaround? Otherwise we are many users that are ruled out of using Acegi. I mean, Isnt WebSphere by far the biggest commercial AppServer? If so, even if IBM is wrong in this case (They probably are :-)) shouldnt Acegi work anyway on it somehow?

                      Best regards,
                      /Fredrik

                      Comment


                      • #12
                        Originally posted by daf6265 View Post
                        Hi, we are also using WebSphere 6.1.0.11 (without the Web Services Feature Pack) and we have the same problem. Is it possible to create a workaround? Otherwise we are many users that are ruled out of using Acegi. I mean, Isnt WebSphere by far the biggest commercial AppServer? If so, even if IBM is wrong in this case (They probably are :-)) shouldnt Acegi work anyway on it somehow?
                        This is really good to hear (now don't get me wrong, please) that it's not just a matter of me beeing stupid. Seems like IBM introduces new regression bugs for each release. Acegi worked in 6.1.0.9 with that far from intuitive com.ibm.ws.webcontainer.invokefilterscompatibility property set to true. Maybe somebody need to teach The Big Company some regression testing? Or maybe it hasn't percolated through all the layers of "managers" in the IBM organization?

                        Maybe, just maybe, the announced 6.1.0.13 (23 nov) may allow us humble user to actually use Java EE by "Write once, run anywhere" even in WebSphere. There's a thought for sore developers.

                        I've gotten accept for using Tomcat in the meantime. I mean, it just works.
                        Last edited by kantorn; Oct 20th, 2007, 04:48 AM.

                        Comment


                        • #13
                          Originally posted by daf6265 View Post
                          ... Even if IBM is wrong in this case (They probably are :-)) shouldnt Acegi work anyway on it somehow?

                          Best regards,
                          /Fredrik
                          Perhaps you'd like to volunteer to maintain a server farm of all major servers (websphere, Oracle AS etc), monitor their minor releases for new bugs and maintain a set of patches for them all to make sure Acegi security "somehow" works with them all .

                          Comment


                          • #14
                            Jira

                            Reported to JIRA (SEC-579) today.

                            Comment


                            • #15
                              Originally posted by Luke View Post
                              Perhaps you'd like to volunteer to maintain a server farm of all major servers (websphere, Oracle AS etc), monitor their minor releases for new bugs and maintain a set of patches for them all to make sure Acegi security "somehow" works with them all .
                              Hi, I get your point :-) Im sure its a daunting task, but WebSphere is probably the biggest server, and WAS 6.1 has been out for 1,5 years now. From what I can read in this forum, there is no version of WAS 6.1 where Acegi has run succesfully.

                              Comment

                              Working...
                              X