Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Already on GitHub? Sign in to your account

SEC-1400: Support composition of intercept-url lists #1643

spring-issuemaster opened this Issue Feb 7, 2010 · 9 comments


None yet
1 participant

Stephen Crawley (Migrated from SEC-1400) said:

I would like the security namespace to be able to specify lists of elements separately from the element, and then wire them into the active element depending some configuration property.

This is illustrative of the kind of thing I would like to be able to do:

    <sec:intercept-url pattern="/images/*" filters="none" />
    <sec:include-intercept-url-list ref="${param}" />
    <sec:intercept-url pattern="/*.gif" filters="none" />

... and in a different file ...

<sec:intercept-url-list id="some-id">
    <sec:intercept-url pattern="/annotea/admin/*" access="ROLE_ADMIN" />
    <sec:include-intercept-url-list ref="some-other-id" />

... and in a Java properties file


Ideally, intercept url lists would be configurable to the same extent that regular spring beans are configurable; e.g. using bean:import, bean:alias, the new Spring EL, PropertyPlaceholderConfigurer and so on. But I'd be happy with anything that allows me to factor out the interceptor lists and compose them under the control of the System properties.

Luke Taylor said:

I think if you want something like this, you're going to have to write your own customization code. It is not something that is likely to be a common requirement. You could use individual FilterSecurityInterceptor instances (and select them based on your requirments) or use your own custom namespace.

Stephen Crawley said:

The first alternative that you suggest amounts to abandoning the use of the security namespace, and distributing SpringSecurity wiring files that rely solely on generic Spring bean wiring syntax. I could probably cope with that, but I don't think that people deploying / tailoring my software would appreciate this ... especially since the current SS documentation no longer covers that approach to SS wiring to the extent that would required by a SS newbie.

The second alternative amounts to creating a semi-private fork of the SS config module. That's going to create a long term maintenance problem for me/my successors, not to mention version conflict problems for downstream folks who may need to mix and match with official Spring / SpringSecurity modules; e.g. pulled in by Maven.

Instead of those, suppose that I developed some patches that implemented the minimal extensions I need. Would you consider reviewing those patches, and once they were in a satisfactory state, integrating them back into the main SS codebase? Are there any prerequisites that would need to be fulfilled before you could accept contributions?

(BTW, I'm also working on Shibboleth authentication and other SS extensions that I'd eventually like to contribute.)

Luke Taylor said:

You wouldn't have to stop using the namespace or fork the codebase.

There no reason why you can't configure the namespace to allow all requests by default and insert a separately configured FilterSecurityInterceptor at the end of the stack, selected as you've defined. There are probably other ways you could do it too, possibly replacing the default interceptor by using a PostProcessor, or using re-injecting it with a custom FilterInvocationDefinitionSource. Or you could define your own separate namespace which is independent of the security one, but takes account of the beans it creates and satisfies your specific configuration needs. This is not uncommon amongst Spring power users. It could be responsible for adding a BeanPostProcessor to the app context, for example.

The point is that this is just one out of many corner cases. There are lots of different ways to configure things and it doesn't make sense for the namespace to support them all. Apart from that it would be very difficult to implement (and maintain) what you are suggesting using namespace parsing. It is much easier to deal with the parsed beans in a post-processor and make modifications to the configuration at that point.

Luke Taylor said:

Regarding shibboleth integration, that would be an interesting submission for the Security extensions project. Contributors need to sign an agreement (similar to an Apache-style one, I believe).

Stephen Crawley said:

I'm trying your suggestion about adding an extra FilterSecurityInterceptor.

Stephen Crawley said:

Well it works, though there are a couple of gotchas:

  1. It is not possible use the filter="none" form of an in a separate FilterSecurityInterceptor. That means I cannot use config switch tricks to select the URL patterns for which the security filters are bypassed.

  2. In order to wire the FilterSecurityInterceptor, you have to set the "authenticationManager" and "accessDecisionManager" properties. The authenticationManager I can name using the "alias" attribute on my element, but there is no advertised id or alias for the AccessDecisionManager that the namespace creates by default. So I have to explicitly configure and wire in an AccessDecisionManager bean that is identical to the one I'd use by default.

Luke Taylor said:

There are always other ways to do things. For example, you can write your own bypass filter and select that in DelegatingFilterProxy rather than "springSecurityFilterChain", having it skip the FilterChainProxy for URLs you don't want to be secured but direct everything else through it.

Enrico Giurin said:

Even I'd be interested to have this feature, which is to have the list of intercept-url in a separated file, out of the http section. I would like to put the list of the intercept-url in the application file while having the general configuration section, in another product configuration file to be reused in many application.

Keith Garry Boyce said:

If you configured a separately configured FilterSecurityInterceptor at the end of the stack you would have to change the FILTER_APPLIED functionality right? hence you have to override the entire FilterSecurityInterceptor Class?

replacing the default interceptor by using a PostProcessor provides no way to specify which bean to replace in which context i.e if you have 2 http sections

@spring-issuemaster spring-issuemaster added this to the 3.0.2 milestone Feb 5, 2016

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment