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 https://github.com/spring-projects/spring-security/issues/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.

Comment From: 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?

Comment From: lrozenblyum

Hello @jzheaux.

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

Comment From: 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?

Comment From: lrozenblyum

@jzheaux the PR was submitted, please take a look: https://github.com/spring-projects/spring-security/pull/12670

Comment From: jzheaux

Sorry for the delay in my response, @lrozenblyum. Please base it off the oldest impacted and supported maintenance branch. In that case, this would be 5.7.x since 5.6.x is no longer supported.