Expected Behavior
Allow the order of the filter being added in AbstractAuthenticationFilterConfigurer.configure to be customized with HttpSecurityBuilder.addFilterBefore or HttpSecurityBuilder.addFilterAfter.
Current Behavior
Currently the configure method in AbstractAuthenticationFilterConfigurer calls HttpSecurityBuilder.addFilter which requires the filter to be a Spring internal filter (or subclass) for ordering purposes. This is not always possible.
Context
We have several configurers that extend AbstractAuthenticationFilterConfigurer that have custom authentication filters/tokens/providers where there is no appropriate filter provided by Spring that can be extended for our needs. By extracting the call to HttpSecurityBuilder.addFilter in the configure method into its own protected method, developers could instead override that method and specify HttpSecurityBuilder.addFilterBefore or HttpSecurityBuilder.addFilterAfter to properly configure the filter order when there is not an appropriate Spring filter to extend.
This would be a very small and minimal impact change to make.
Example of extracted method:
/**
* Adds the filter to {@link HttpSecurityBuilder}. Override this method to use
* {@link HttpSecurityBuilder#addFilterBefore} or {@link HttpSecurityBuilder#addFilterAfter}
* when using {@link HttpSecurityBuilder#addFilter} isn't appropriate.
*/
protected void addFilter(final B http, final F filter) {
http.addFilter(filter);
}
I am happy to provide a pull request if this is acceptable.
Comment From: jzheaux
Thanks for the suggestion, @scoldwell. The JavaDoc for AbstractAuthenticationFilterConfigurer states:
/**
* Base class for configuring {@link AbstractAuthenticationFilterConfigurer}. This is
* intended for internal use only.
*/
Given that, I don't think we should make changes to it unless it's something that is needed internally.
That said, I'd be happy to lend a hand to see if there is a more idiomatic way to achieve what you are trying to do. If you'd like that, please post a StackOverflow question with an example class that is extending AbstractAuthenticationFilterConfigurer and post a link to the question here.
Comment From: scoldwell
@jzheaux I did see that of the javadoc comment in AbstractAuthenticationFilterConfigurer. Personally, I think that decision should be reconsidered due to the usefulness of AbstractAuthenticationFilterConfigurer for 3rd party developers, but obviously that's not up to me 😄 I will post over on SO as you suggest. Thanks!