Webapp configured with error-page seems to lose security after error on Tomcat

[djgraff209]

I've run into a container issue (Tomcat vs Jetty) ...

I've got a spring security configured app running. The web.xml configures error pages for 404, 403, 500 to map to controller references within the security configured area. The controllers simply render a tiles based error view.

The tiles based view contains the standard application menu we've created.

Under Jetty, if the user then clicks a link within that menu (which keeps them within the secured context) they are brought to the appropriate page.

Under tomcat however, the spring-security filter-chain kicks in and forces a re-authentication ... this unfortunately seems to trash all kinds of things in the session. As a result our app becomes unusable under Tomcat.

Has anyone seen this behavior or has any pointers on how to possibly diagnose what's going on?

Thanks!

[Michael-O]

Editing my post:

After further evaluation, I am struggling with the same exact problem. If the first auth fails, the custom error page gets forwarded, Spring Sec intercepts and tries to reauth. And so on. It does not notice that auth has already failed. I cannot tell it's whether Tomcat or Spring Security. But since Spring Security performs auth, it must be the source of error.

I was able to reproduce this with the default basic filter with a LdapBindAuthenticator. I have found a resembling thread but with no real solution for that problem.

Here is my config:

I am on Tomcat 6.0.35, Spring Security 3.1.2, Spring 3.1.2

web.xml:

<servlet-mapping>
	<servlet-name>dispatch</servlet-name>
	<url-pattern>/</url-pattern>
</servlet-mapping>

<filter-mapping>
	<filter-name>springSecurityFilterChain</filter-name>
	<url-pattern>/*</url-pattern>
	<dispatcher>REQUEST</dispatcher>
	<dispatcher>ERROR</dispatcher> <!-- This is necessary otherwise the security context won't be available on that pages -->
</filter-mapping>

<!-- error pages -->
<error-page>
	<error-code>401</error-code>
	<location>/errors/401</location>
</error-page>

<error-page>
	<error-code>403</error-code>
	<location>/errors/403</location>
</error-page>

<error-page>
	<error-code>404</error-code>
	<location>/errors/404</location>
</error-page>
	
<error-page>
	<error-code>500</error-code>
	<location>/errors/500</location>
</error-page>

A controller handles all /errors/* requests.

spring-security.xml

<beans:bean id="securityContextPersistenceFilter"
		class="org.springframework.security.web.context.SecurityContextPersistenceFilter" />

<security:http pattern="/ext-resources/**" security="none" />
<security:http pattern="/resources/**" security="none" />
	
<security:http use-expressions="true" realm="My Application">
	
	<security:intercept-url 
			pattern="/app/**" 
			access="hasRole('User')" />
			
		<security:intercept-url 
			pattern="/admin/**" 
			access="hasRole('Admin')" />
			
		<security:logout invalidate-session="true" delete-cookies="JSESSIONID"
			logout-url="/logout" logout-success-url="/logout-success" />
			
		<security:http-basic />
		
	</security:http>

<!-- followed by the LDAP configuration -->

If you remove the custom error pages, Tomcat's error report valve works as expected.

So, what can we do here? Is there an error in our logic?

Saying

<security:http pattern="/errors/401" security="none" />

may here for this page but what about 500? This page cannot be set to none. I'd like to retain the security there while displaying the occured error.

[djgraff209]

That is more or less the behavior that I'm seeing under Tomcat. Jetty 8.x doesn't seem to exhibit the behavior so it must be some interaction with Tomcat that may be unintended. Judging by some of the quirks I've seen with Tomcat in the last month or so I'm assuming Tomcat is doing something wonky.

[Michael-O]

This actually not a Tomcat problem. This is a common problem with the filter archtecture. I have filed an issue already https://jira.springsource.org/browse/SEC-2054