Acegi stop working with WebSphere v6.0.2.5?

[pea1]

Anybody else having this experience? I'm developing in Rational Application Developer 6.0.1.1 with WebSphere runtime 6.0.0.0 and Acegi is (mostly) working just fine. Specifically, Acegi is catching that my admin pages are secured and that it needs to prompt for authentication when someone navigates there.

I just tried upgrading the WebSphere Test environment server runtime to 6.0.2.5 (via the Rational Product Updater). Now, the exact same Spring/Acegi app no longer secures my admin pages-it just let's anybody see them.

I've rolled-back and applied the runtime upgrade several times and see the same thing each time.

Anybody else have this experience? Anybody running Acegi with WebSphere 6.0.2.5+ (as a RAD test env or as stand-alone)?

[dejan]

I'm working with Acegi RC-2 and WebSphere 6.0.2.5 on Win2003 server and everething works OK (for production and for developing application)
I have some problems with 6.0.2.7 patch but I have no time to find what's the problem.

[pea1]

Mmmm. I'm using Acegi 1.0.0RC2 and delpoying to a WebSphere 6.0.0.0 test server on Windows XP; that works. When I upgrade the test server to 6.0.2.5, I it stops working. I don't currently have another 6.0.x server to try this out on.

[Ben Alex]

Try going through the DEBUG logs, comparing the working and non-working versions. See if you can narrow down the cause by this simple comparison. Please let me know how you go.

[pea1]

Here's about more info about this problem in v6.0.2.5.

It's looking like the filter chain proxy (org.acegisecurity.util.FilterToBeanProxy) isn't getting invoked anytime when the URL ends with "/". Thus when I navigate to a nominally protected url myserver.com/admin/, I'm not seeing any debuggin output from Spring or Acegi, except notification that

[4/14/06 12:49:08:385 EDT] 0000002c RequestContex 1 org.springframework.web.context.scope.RequestContextListener requestInitialized Bound request context to thread: com.ibm.ws.webcontainer.srt.SRTServletRequest@4e14e213
[4/14/06 12:49:08:401 EDT] 0000002c RequestContex 1 org.springframework.web.context.scope.RequestContextListener requestDestroyed Cleared thread-bound request context: com.ibm.ws.webcontainer.srt.SRTServletRequest@4e14e213

On the other hand, when I navigate to "admin/bob", I see logging where Acegi is invoked and tells me it's checking for URL matches to invoke security constraints.

This is all with Acegi Filter Chain proxy setup as follows

	<filter>
		<description>
		</description>
		<display-name>
		Acegi Filter Chain Proxy</display-name>
		<filter-name>Acegi Filter Chain Proxy</filter-name>
		<filter-class>org.acegisecurity.util.FilterToBeanProxy</filter-class>
		<init-param>
			<description>
			</description>
			<param-name>targetBean</param-name>
			<param-value>filterChainProxy</param-value>
		</init-param>
	</filter>
	<filter-mapping>
		<filter-name>Acegi Filter Chain Proxy</filter-name>
		<url-pattern>/*</url-pattern>
	</filter-mapping>

Right now this looks like a WebSphere issue failing to invoke the filter.

[Ben Alex]

Just rule out it's not an Acegi Security issue by replacing the FilterToBeanProxy with just a debug filter that System.out.println("Filter invoked"). If you can't see it being invoked, I'd take it up with WebSphere support.

[pea1]

This definitely was a WebSphere 6.0.2.5 issue (at least on my installation). I have since upgrade to version 6.0.2.7, and the problem disappeared.

[Raichura]

I am seeing the same issue where Acegi 1.0.3 in WAS 6.1.0.0 and 6.1.0.5 allows users to see my index.jsp where it doesn't in Tomcat. The URL to my app is "http://localhost:9080/myapp" and it gets redirected to "http://localhost:9080/myapp/index.jsp". I have debugged it into org.acegisecurity.util.UrlUtils.java in method "getRequestUrl(FilterInvocation fi)". In Tomcat, this method returns "/index.jsp" whereas in WAS it returns "/" (because r.getQueryString() returns a null). As a result, in org.acegisecurity.intercept.web.PathBasedFilterInv ocationDefinitionMap, there isn't a match between the "/" and what I have mapped for URL Security. I don't have anything mapped to "/" nor do I want to. So Acegi happily allows users to see my index.jsp unauthenticated. Any help would be appreciated.

[pea1]

Maybe what you could do is work around the problem by restructuring your URIs. Move your index.jsp into /myapp/index/index.jsp. Put JSP page at /myapp/index.jsp that simply redirects to /myapp/index/index.jsp.

I would hope that you change your security def to apply to "/index", whereas you can't really apply it to just "/ ".

[Raichura]

Thanks pea1. I suppose that would work and I will put that in my back pocket incase I can't find a more elegant solution. You can apply security to just "/". Here is my objectDefinitionSource for FilterSecurityInterceptor (simplified):

<property name="objectDefinitionSource">
<value>
CONVERT_URL_TO_LOWERCASE_BEFORE_COMPARISON
PATTERN_TYPE_APACHE_ANT
/**/*.html=ROLE_USER
/**/*.jsp=ROLE_USER
/**/*.do=ROLE_USER
</value>
</property>

You can do the following to add security to everything:

<value>
CONVERT_URL_TO_LOWERCASE_BEFORE_COMPARISON
PATTERN_TYPE_APACHE_ANT
/login.jsp*=ROLE_ANONYMOUS
/**=ROLE_USER
</value>

This way, everything is secured except login.jsp. I have tried this but my login.jsp and index.jsp looks pretty funky as if it can't get access to the CSS files. But once I am logged in, everything looks fine. I suppose re-ordering the filters might do the trick so that the filter responsible for authentication comes first. I currently have it as: httpSessionContextIntegrationFilter,logoutFilter,a uthenticationProcessingFilter,securityContextHolde rAwareRequestFilter,rememberMeProcessingFilter,ano nymousProcessingFilter,exceptionTranslationFilter, filterInvocationInterceptor

Anyway, I will fiddle with it more. Thanks.