intercept-url for nested URLs not working if both access and filters are used

[spiff]

Hi,

Before opening a JIRA for this, I would like to get your feedback first. Consider the following applicationContext.xml snippet:

<sec:http entry-point-ref="entryPoint">
	<sec:intercept-url pattern="/images/login/**" access="ROLE_RETAIL_CUSTOMER" />
	<sec:intercept-url pattern="/css/**" filters="none" />
	<sec:intercept-url pattern="/images/**" filters="none" />
	<sec:intercept-url pattern="/scripts/**" filters="none" />
	<sec:intercept-url pattern="/favicon.ico" filters="none" />

	<sec:intercept-url pattern="/index.html" filters="none" />
	<sec:intercept-url pattern="/login.html" filters="none" />
	<sec:intercept-url pattern="/quit.html" filters="none" />

	<sec:intercept-url pattern="/doLogin.html" access="ROLE_ANONYMOUS,ROLE_RETAIL_CUSTOMER" />
	<sec:intercept-url pattern="/**" access="ROLE_RETAIL_CUSTOMER" />

	<sec:access-denied-handler ref="accessDeniedHandler" />

	<sec:form-login
		login-page="/login.html"
		login-processing-url="/doLogin.html"
		default-target-url="/secure/home.html"
		always-use-default-target="true"
		authentication-failure-handler-ref="presentationTierAuthenticationFailureHandler"
	/>

	<sec:session-management invalid-session-url="/timedout.html">
		<sec:concurrency-control max-sessions="1" error-if-maximum-exceeded="true" expired-url="/timedout.html" />
	</sec:session-management>
</sec:http>

Notice the intercept-url elements for /images/login/** and /images/** , the first being nested within the second, the first having an access attribute, and the second having a filters attribute.

Given this configuration, Spring Security will not apply access control to requests to /images/login/1.jpg . To me, this looks like a bug.

From what I've gathered during my debug session, the HttpSecurityBeanDefinitionParser seems to be creating two maps: a first order-preserving map filled first with intercept-url with filters="none" (HttpConfigurationBuilder.parseInterceptUrlsForEmp tyFiltersChains) and second with the remaining intercept-url (not sure where exactly). Once this is done, the /images/** entry has a lower position than the /images/login/** entry because of its filters="none" attribute. When an incoming request is received, the FilterChainProxy iterates through the ordered map entries and checks if the the URL matches the entry key. In the case of the /images/login/1.jpg URL, the /images/** entry comes up first, and matches the incoming URL, so no filters are applied.

As a workaround, we created an intercept-url for a different path (/images_login/**) to avoid the path nesting.

I'm not sure exactly why entries with filters="none" are put first in the ordered map, maybe for performance reasons, but it seems to be causing our problem. Am I missing something or is this a bug?

Thanks!

[Luke Taylor]

The problem is that there are actually two independent things being configured by intercept-url here. A related discussion can be found in SEC-1475. Essentially, in 3.0.x, using filters="none" defines a separate empty filter chain, whereas the "access" attribute configures the FilterSecurityInterceptor in the default filter chain (which is mapped to "/**"). If you use filters="none" for a pattern, Spring Security ignores it completely. An alternative is to define a pattern as allowing anonymous access, which will give you the behaviour you want.

In 3.1, the filters="none" syntax is no-longer supported. You can use additional <http> elements to define separate filter chains, including unsecured ones. So there are two separate sets of ordering which apply: the order of the <http> elements (and thus filter chains) and the ordering of patterns which is applied by the FilterSecurityInterceptor within each chain.

[spiff]

Allright, thanks Luke!