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-1290: OrderedFilterBeanDefinitionDecorator enforces "order" attribute for custom filter #1517

spring-issuemaster opened this Issue Nov 10, 2009 · 3 comments


None yet
1 participant

Johannes Scharf (Migrated from SEC-1290) said:

The javadoc of OrderedFilterBeanDefinitionDecorator says:
If the user's filter already implements Ordered, and no "order" attribute is specified, the filter's default order will be used.

When a custom filter is specified via a "custom-filter" element without an "after", "before" or "position" attribute in the configuration, altough it implements the "Ordered" interface, the OrderedFilterBeanDefinitionDecorator always throws the exception:
org.springframework.beans.factory.parsing.BeanDefinitionParsingException: Configuration problem: A single 'after', 'before', or 'position' attribute must be supplied

This behaviour obvisiously violates the contract defined by the javadoc and the documentation of the "custom-filter" element.

I think the problem is at line 63 of the OrderedFilterBeanDefinitionDecorator class. It would be sufficient to remove that code as the "order" attributes are checked again at line 110 with respect if the filter implements at least the "Ordered" interface.

Johannes Scharf said:

This affects at least version 2.0.5 of Spring Security.

Luke Taylor said:

This is essentially an out-of-date doc issue. The intention is now that you should specify the position of the filter relative to the filter stack, rather than by using explicit order values. The latter approach is fragile, as filters may be added or removed to the stack with new versions of the framework and users need to know the order numbers assigned to the internal filters. There is no benefit over using a relative positioning approach.

In 3.0, the filter chain order is determined before the beans in the application context are actually instantiated, so by the time the order obtained from the filter instance was obtainable, it would be too late.

Luke Taylor said:

Closing as "won't fix? since this doesn't apply to 3.0

@spring-issuemaster spring-issuemaster added this to the 3.0.0.RC2 milestone Feb 5, 2016

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