Announcement Announcement Module
Collapse
No announcement yet.
problems with Acegi and WebSphere 6.1 Page Title Module
Move Remove Collapse
This topic is closed
X
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • problems with Acegi and WebSphere 6.1

    I've just run into a problem with a Spring/Acegi web app, trying to run it on a WebSphere 6.1.0.5 server. Basically, it appears that WebSphere v6.1.0.5 (and at least v.6.1.0.3) has a bug that generates a 404 error instead of invoking filters on URI requests that aren't actually present in the web app.

    This means that /myapp/j_acegi_security_check returns a 404 instead invoking ANY of the filters for the app (including ones with URI patterns like /*). So Acegi doesn't appear to function with 6.1.0.3/5, which are the versions that I've actually tried.

    This issue is similar to IBM bug PK27620, http://www-1.ibm.com/support/docview...id=swg1PK27620, which describes the same filter issue, only specifically with JSP resources. That bug is supposed to have been fixed in v6.1.0.3.

    It looks like the issue I describe is a variant of that problem. I have submitted a problem report to IBM.

    Has anybody found a workaround to get Acegi working?

    I'm using Acegi 1.0.2/3.

  • #2
    solved

    I got a response from IBM. They ackowledge this problem and gave me a work-around.
    One of our level 2 technicians stated this about the apar...
    "APAR PK27620 changed a lot of the code dealing with filters. We had to
    add a property in our methods to keep certain functionality. While
    fixing some problems it(the apar) has changed the behaviour of certain
    filter functionality. So we had to add a new custom property for
    6.1.0.3+"

    The custom property he is talkin about is;
    com.ibm.ws.webcontainer.invokefilterscompatibility

    The com.ibm.ws.webcontainer.invokefilterscompatibility should be set to
    true
    through Application Servers -> <server> -> Web Container Settings -> Web
    Container -> Custom Properties. Once set, you don't need to remove this
    custom property even if you upgrade the WAS.
    I tried this and it appears to work for me. Here's a similar issue: http://www-1.ibm.com/support/docview...=utf-8&lang=en

    Note, that I have some other apps using Acegi 1.0.2 on WebSphere 6.1.0.3 and they weren't having this issue, so it's not a consistent problem.

    Comment


    • #3
      I am having the same issue. But the fix doesn't seem to work. It worked once, but then when I tried it on a different machine it didn't work. You mentioned that the issue occurs randomly, any idea why that happens?

      My env is WAS 6.1 with fix pack 6.1.0.3. I added the custom property as well.

      Comment


      • #4
        Originally posted by pea1 View Post
        I got a response from IBM. They ackowledge this problem and gave me a work-around.


        I tried this and it appears to work for me. Here's a similar issue: http://www-1.ibm.com/support/docview...=utf-8&lang=en

        Note, that I have some other apps using Acegi 1.0.2 on WebSphere 6.1.0.3 and they weren't having this issue, so it's not a consistent problem.
        There are a lot of fixes available. I installed the 32-bit x86 AMD/Intel AppServer fix. Do I need to install any other?

        Comment


        • #5
          Sorry, all I know is that the fix worked for an Acegi app that previously wasn't working on 6.1.0.3. The mystery to me is that I have other apps running in the same WebSphere cell on the same hardware, but on a different app server instance, that were useing Acegi just fine without the fix.

          Comment


          • #6
            There were a lot of fixes for the AppServer, Client, HttpServer etc... I used the Appserver fix. is that right? Do I need to install the latest fix as well.

            I might as well get a lottery.

            Comment


            • #7
              All I did was install 6.1.0.3 on the app server and set the custom property. No other fixes were involved.

              Comment


              • #8
                Tried the same and did not work....

                Anyways, thanks for the responses.

                Comment


                • #9
                  Fixed

                  Hi guys, I had this problem, and now it's fixed. Had to set the com.ibm.ws.webcontainer.invokefilterscompatibility to get the Struts2 and Sitemesh filters to work with 6.1.0.5.

                  Thanks heaps for your input!!

                  More details here:
                  http://www.nabble.com/forum/ViewPost...31115&framed=y

                  Comment


                  • #10
                    what about j_acegi_logout?

                    Seems like the fix only works fine for the login part.

                    When using Acegi's LogoutFilter (mapped on /j_acegi_logout) it seems that WAS v6.1 calls the logouthandlers set in the logout filter get called twice. As such the session is recreated, and for some other reason the delete of the remember-me cookie gets lost somewhere due to WASv6.1 not handling filter logic as should.

                    On WASv6.0, Tomcat4 and Tomcat5.4 the logout works fine.

                    Did someone manage to write acegi logout code that actually works on Websphere v6.1?

                    Comment


                    • #11
                      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


                      • #12
                        Thanks for the heads-up. Do you happen to know which APAR references the fix in the list (http://tinyurl.com/35r3nt for the entire list).

                        Rob

                        Comment


                        • #13
                          Apar

                          Normally, I'd guess it already would have been fixed in FP6.1.0.9, since this description fits what was happening: http://www-1.ibm.com/support/docview...id=swg1PK31377 (and then you'd obviously still need to set the 'com.ibm.ws.webcontainer.invokeFiltersCompatibilit y' property to true).

                          But it didn't entirely fix the acegi problems. It did only fix the login part, but not the logout part (and then you'd obviously still need to set the 'com.ibm.ws.webcontainer.invokeFiltersCompatibilit y' property to 'true').

                          I didn't really find any fix in the 6.1.0.11 FP that matches the logout problem sequence of events, although it is fixed now...
                          Last edited by wpraet; Sep 12th, 2007, 04:02 AM. Reason: typo in FP version

                          Comment


                          • #14
                            Thanks for the reply. I'm surprised to hear about the logout issue because I haven't experienced any problems with the logout filter.

                            Comment


                            • #15
                              Originally posted by robmoore View Post
                              Thanks for the reply. I'm surprised to hear about the logout issue because I haven't experienced any problems with the logout filter.
                              FYI the problem still exists in WAS 6.1 FP 11, at least on the local version of WAS 6.1 that ships with RAD 7, and that is with com.ibm.ws.webcontainer.invokefilterscompatibility set to true

                              Comment

                              Working...
                              X