NPE in HttpSecurity#addFilterBefore when mixing custom DSL and standard

[lrozenblyum]

Describe the bug
We get an NPE when we try to add a new filter using standard DSL relative to another filter that was registered via custom DSL.
This looks like a different scenario than #9787

To Reproduce
Spring Security version: 5.8.1

// here we have to use a custom DSL because getting AuthenticationManager is really painful now
private class CustomConfigurer extends AbstractHttpConfigurer<CustomConfigurer, HttpSecurity> {
        @Override
        public void configure(HttpSecurity http) throws Exception {
	        AuthenticationManager authenticationManager = http.getSharedObject(AuthenticationManager.class);
        
	        http.addFilterBefore(new CustomFilter(authenticationManager), LogoutFilter.class);
        }
}

@Bean SecurityFilterChain securityFilterChain(HttpSecurity http) throws Exception {
        http.apply(new CustomConfigurer());
        httpSecurity.addFilterBefore(new Filter2(), CustomFilter.class); // NPE here inside addFilterBefore
        return http.build();
}

Expected behavior

1. I would expect it's possible to mix registration of filters via standard and custom DSL.
2. In any case org.springframework.security.config.annotation.web.builders.HttpSecurity.addFilterAtOffsetOf(Filter, int, Class<? extends Filter>) NPE seem not to be graceful - compare with org.springframework.security.config.annotation.web.builders.HttpSecurity.addFilter(Filter) which at least validates and throws some more meaningful exception

A workaround exists: the second filter must be also applied via a custom DSL.

[jzheaux]

@lrozenblyum, thanks for reporting this. I believe the issue is that a configurer's configure() method is called by build(). The above code is attempting to add Filter2 before CustomFilter has been registered.

This is a consequence of constraints in your scenario -- you are saying that you need the AuthenticationManager, which is not available at the time apply is called. If you can unravel the constraints, say by constructing your own AuthenticationManager, then you would be able to list the filters separately. (As you said, referencing them both in the same configurer also solves this.)

Agreed that it should throw a more meaningful exception. Are you able to provide a PR along those lines?

[lrozenblyum]

Hello @jzheaux.

I think I can provide a PR with the meaningful exception handling

[lrozenblyum]

@jzheaux according to the contributor's guide, a PR should be opened from oldest maintenance branch.

Is it 5.6.* (as it is available in the https://github.com/spring-projects/spring-security/milestones page)?
It seems it hasn't been updated for 8 months, so wondering: is it a correct base to work on?

[lrozenblyum]

@jzheaux the PR was submitted, please take a look: #12670