Spring Security
  1. Spring Security
  2. SEC-1290

OrderedFilterBeanDefinitionDecorator enforces "order" attribute for custom filter

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Minor Minor
    • Resolution: Won't Fix
    • Affects Version/s: None
    • Fix Version/s: 3.0.0.RC2
    • Component/s: Namespace
    • Labels:
      None

      Description

      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.

        Activity

        Hide
        Johannes Scharf added a comment -

        This affects at least version 2.0.5 of Spring Security.

        Show
        Johannes Scharf added a comment - This affects at least version 2.0.5 of Spring Security.
        Hide
        Luke Taylor added a comment -

        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.

        Show
        Luke Taylor added a comment - 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.
        Hide
        Luke Taylor added a comment -

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

        Show
        Luke Taylor added a comment - Closing as "won't fix? since this doesn't apply to 3.0

          People

          • Assignee:
            Luke Taylor
            Reporter:
            Johannes Scharf
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: