I am attempting to use PrettyFaces on a WebSphere 7 server that has application security enabled. The issue appears to be that if a URL does not map to an actual file in the web application, WebSphere will return a HTTP error 404 (in addition to a WWW-Authenticate header!). I’m curious if anyone else has gotten snagged by this issue, either with PrettyFaces or even their own custom servlet filters that at mapped to non-file URLs.
Several discussions on the internet (as well as the PrettyFaces docs) seem to indicate that using the server parameter com.ibm.ws.webcontainer.invokefilterscompatibility=true will work, but most of the references seem to be using WebSphere 6.1 (I’m on version 7).
The issue does not occur when the application is *not* using JEE server security.
I think I found my answer – there is another WebSphere parameter com.ibm.ws.webcontainer.assumefiltersuccessonsecurityerror that also must be set to true. This may come in handy for some other unfortunate WebSphere user out there trying to use PrettyFaces with app security enabled.
When a request is received for a static file which does not exist, the web container calls defined servlet filters. If the filters do no successfully complete, a 404 error code is set. In a situation where application security is enabled, a security check is performed as part of filter invocation. Typically if the security check fails the web container considers the filters to have failed and still sets a 404 error code instead of the 401 error code that indicates the failure of a security check. The 404 error code enables the requester to access the static file without logging on.
You can set the com.ibm.ws.webcontainer.assumefiltersuccessonsecurityerror custom property to true, to prevent the 401 error code from being replaced with a 404 error code, and ensure that a user must enter a valid user ID and password before they can access a static file.