Strange 404/j_security_check error with Websphere 6.1

Question

I have a websphere 6.1 configuration and the application is running, but some requests go to j_security_check but the last one (there are filters associated with J_security_check) will generate a 404 error.

For example:

(1) User posts to: http://localhost:9081/Page/j_security_check And it works on Filter1, but later requests to Filter2 get a 404 error.

(1a) Note, the following filters are associated with j_security_check:

<filter-mapping>
     <filter-name>Filter1</filter-name>
     <url-pattern>/j_security_check</url-pattern>
    </filter-mapping>
    <filter-mapping>
     <filter-name>Filter2</filter-name>
     <url-pattern>/j_security_check</url-pattern>
    </filter-mapping>

(2) The code reaches the filter code:

chain.doFilter(req, res);

WASReqURL has the following cookie value, this is needed by j_security_check: http://localhost:9081/Test/test.html

Ideally, the client should end up on 'http://localhost:9081/Test/test.html'

But, I get a 404 error at a subsequent request to j_security_check: http://localhost:9081/Page/j_security_check

Also, here is relevant snippet in the web.xml file.

<login-config>
 <auth-method>FORM</auth-method>
 <form-login-config>
  <form-login-page>/Go</form-login-page>
  <form-error-page>/Go</form-error-page>
 </form-login-config>
</login-config>

---

The question is, what controls 'J_security_check' from the websphere perspective.

Details: RAD7 Websphere Server 6.1, local box

Answer 1

Couldn't find the answer

Answer 2

This is a very well known issue with WebSphere 6.1 and Spring Security.

You need to add this variable to the server properties using the admin console:

    com.ibm.ws.webcontainer.invokefilterscompatibility = true

also i remember you need to install some patch for websphere, depending on the exact version.

Just look in internet about the variable I mention and you will find the solution...

Hope it helps ...

Miguel

Answer 3

I am using WebSphere 6.1 with the fix pack 23 installed and the j_security_check can be accessed correctly.