As I have recently found out by the school of hard knocks, these two do not mix when Java EE web container security is enabled.
Struts2 is the follow on to the very popular and ubiquitous framework Apache Struts. Struts2 is actually a combination of Struts and WebWorks and is a really slick framework. The more I used it the more I liked it (sans the crap with security issues). Under Stuts1, the framework was built around a Struts action servlet. Under Struts2, struts operates under servlet Filter which is where the problem comes in for WebSphere.
The Problem:The problem arises when you need to turn on container based security. This is enabled in the web.xml file:
Whenever a user browses within the application to a URL that has customer in the string, it should prompt the user for security credentials with a login page. This happens quite easily in Apache Tomcat, but WebSphere just navigates right to the secured resource without ever grabbing credentials. This happens in WebSphere App Server 6.1 and 7.0, and it is a certified bug, even when enabling the custom JVM property com.ibm.ws.webcontainer.disablesecuritypreinvokeonfilters=true
The Solution:For WAS 6.1, upgrade to fixpack 23 (220.127.116.11), and enable the custom property. This fixpack has already been released. If you have developed your application under WAS 7.0 and are using servlet spec 2.5 and JDK 6, then you'll have to wait for fix pack 18.104.22.168 which is due in July/August time frame. Otherwise, you will have to create a whole new application to deploy under JDK 5 to deploy to WAS 6.1 and copy over your compatible Java artifacts. The easy solution is to use Apache Tomcat in the interim.
Here are some other links to the issue:
Labels: struts2, WAS, WAS7