SpringBoot Load order for Filters in AutoConfiguration overwritten by SpringSecurityFilterChain in implementing project?

I am trying to create a load order in autoconfiguration files for the following filters:

@Bean
public FilterRegistrationBean<RequestParamsFilter> requestParamsFilter(){
    FilterRegistrationBean<RequestParamsFilter> registrationBean = new FilterRegistrationBean<>();
    registrationBean.setFilter(new RequestParamsFilter(principle, apiCacheService));
    registrationBean.setOrder(1)
    registrationBean.addUrlPatterns("/*");
    return registrationBean;
}

@Bean
public FilterRegistrationBean<ParamsMarshallerFilter> paramsMarshallerFilter(){
    FilterRegistrationBean<ParamsMarshallerFilter> registrationBean = new FilterRegistrationBean<>();
    registrationBean.setFilter(new ParamsMarshallerFilter(buildProperties, ctx, apiProperties));
    registrationBean.setOrder(2)
    registrationBean.addUrlPatterns("/*");
    return registrationBean;
}

Unfortunately, in the demo project, once the SecurityConfig creates a SpringSecurityFilterChain, I have to create the load order under 'configure()' (in the implementing project) as it just DROPS my filter load order:

    httpSecurity.addFilterBefore(paramsMarshallerFilter, UsernamePasswordAuthenticationFilter.class);
    httpSecurity.addFilterAfter(requestParamsFilter, ParamsMarshallerFilter.class);

Is there a way to set the load order for a SpringSecurityFilterChain in an autoconfiguration PRIOR to loading into the project that integrates with SpringSecurityFilterChain??

NOTE : I have tried setOrder and the @Order annotation and also 'spring.security.filter-order=3' (in application.properties') of the autoconfiguration (to no effect)

Can add to project if you want to see code prior to launch.

Comment From: orubel

I'm just going to move functionality from one filter to abstract class for an interceptor for before() / after().

Its a working solution but was hoping for something better.

Comment From: orubel

I am beginning to think this may be an autoconfiguration that I should be excluding (either in the autoconfiguration setup or the project itelf). More than happy to help test.

Thoughts?

Comment From: kse-music

can you show your example in detail?

Comment From: orubel

sure. I've changed it but in looking back at the history, it looked like the following

    @Bean
    public FilterRegistrationBean<RequestParamsFilter> requestParamsFilter(){
        FilterRegistrationBean<RequestParamsFilter> registrationBean = new FilterRegistrationBean<>();
        registrationBean.setFilter(new RequestParamsFilter(principle, apiCacheService, apiProperties));
        registrationBean.setOrder(2)
        registrationBean.addUrlPatterns("/*");
        return registrationBean;
    }

    @Bean
    public FilterRegistrationBean<RequestInitializationFilter> requestInitializationFilter(){
        FilterRegistrationBean<RequestInitializationFilter> registrationBean = new FilterRegistrationBean<>();
        registrationBean.setFilter(new RequestInitializationFilter(buildProperties, ctx, apiProperties));
        registrationBean.setOrder(1)
        registrationBean.addUrlPatterns("/*");
        return registrationBean;
    }

and then I set the filter order in the application properties:

spring.security.filter-order=3

But when the autoconfig is used in a project with spring security, that filter order is ignored and they are loaded in a reverse order... ALWAYS!

I have tried switching the order and it doesn't help. It's a tad bizarre. Naturally I'm assuming its me.

Comment From: kse-music

what's you spring boot version? In my spring boot 2.5.8 ,the config key is spring.security.filter.order not spring.security.filter-order

Comment From: philwebb

@orubel Are you able to attach or share a project that we can run and debug?

Comment From: orubel

I have since removed the filter as I didn't finding any way to do this and the answers on stackoverflow were only that this had to be added/changed in the demo-project and that there was no solution for autoconfiguration.

I wish I did still have the code for you to test but at least I can make you aware of this in case you feel this is something to look into.

Should I be enforcing security in the autoconfig or allowing end user to implement their own security choices? If so this answers a few of my probs and I can implement filterchain and this solves issues.

Comment From: philwebb

We used to do quite a bit of security auto-configuration in Spring Boot 1.x but we found it very hard to always get right. In Spring Boot 2.x we intentionally left security configuration up to users and offered utilities (such as org.springframework.boot.autoconfigure.security.servlet.PathRequest) so that they could write and reason about their SecurityWebFilterChain beans.

My recommendation is not try and be too smart with security auto-configuration.

Comment From: orubel

Excellent. Thats kinda what I thought answer was going to be so I moved to something more basic that did same thing. :)

Thank you for your help kind sir.