SEC-3156: Cannot replace a standard filter

[spring-projects-issues]

Keith Garry Boyce (Migrated from SEC-3156) said:

It says here that a filter can be replaced.
position The explicit position at which the custom-filter should be placed in the chain. Use if you are replacing a standard filter.

Then here is says:

Note that you can’t replace filters which are created by the use of the element itself

I have a use case where I want a bean to maintain the set of intercept urls that pertain to a particular http tag. Hence I either need to replace the FilterSecurityInterceptor with one where I can pass my own SecurityMetadataSource or the code base needs to be modified where I can supply my own custom SecurityMetadataSource per http tag.

I see no reason why this restriction is in place. Also if there is a valid reason then the documentation should be changed so there is no conflict.

I'm at a loss currently as to how to implement my usecase without replacing the entire filter chain which I would prefer not doing. The after and before attributes could be made smarter so it's not just a -1 or +1 on the order and intead an offset attribute could allow me to specific the number to add to the order so I can have up to 100 things between the standard filters rather than just 2

[jzheaux]

I have a use case where I want a bean to maintain the set of intercept urls that pertain to a particular http tag.

It sounds like what you want is to invoke a separate filter chain per set of URLs. It's not clear to me why this is a problem, but perhaps you could elaborate?

Hence I either need to replace the FilterSecurityInterceptor with one where I can pass my own SecurityMetadataSource

Assuming, though, that a custom metadata source is what you need, the metadata source can be changed through an ObjectPostProcessor for Java projects or a BeanPostProcessor for XML projects. The Object given to SecurityMetadataSource is of type FilterInvocation, which contains the HttpServletRequest. Given that multiple filter chains would require analyzing the HttpServletRequest to distinguish which chain to select, the same business logic could be used in this custom metadata source implementation.

Or Spring Security 5.5 released a new API that supercedes FilterSecurityInterceptor that you might consider. AuthorizationManager can be used to achieve the same ends with less configuration. For example:

http
    .authorizeHttpRequests((authorize) -> authorize
        .anyRequest().access(myAuthorizationManager)
    );

(XML support forthcoming)

Where AuthorizationManager also has an instance of FilterInvocation and can return a "yes" or "no" decision.

[spring-projects-issues]

If you would like us to look at this issue, please provide the requested information. If the information is not provided within the next 7 days this issue will be closed.

[spring-projects-issues]

Closing due to lack of requested feedback. If you would like us to look at this issue, please provide the requested information and we will re-open the issue.