Create a class analogous to AbstractHttpConfigurer for reactive applications

[shamrai-dev]

Expected Behavior Need to have an ability to get access to a ServerHttpSecurity object after it has been instantiated in a developer's code. For Servlet applications I can use this:

/resources/META-INF/spring.factories

org.springframework.security.config.annotation.web.configurers.AbstractHttpConfigurer = \
  com.company.oauth.MyOAuth2Configurer

final class MyOAuth2Configurer extends AbstractHttpConfigurer<MyOAuth2Configurer, HttpSecurity> {

    @Override
    public void init(HttpSecurity http) throws Exception {

        ApplicationContext context = http.getSharedObject(ApplicationContext.class);
        //Do some actions
    }
}

For Webflux/Reactive applications there is no such class.

Current Behavior

No ability to get access to a ServerHttpSecurity object after it has been instantiated in a developer's code.

[jzheaux]

Thanks for the report, @shamrai-dev.

We probably want to rethink how this is done with ServerHttpSecurity. Can you elaborate on what specifically you are trying to do?

[renato-zannon]

Hello,

Not sure if I have the same use case as @shamrai-dev, but I was also surprised to learn there's no equivalent to AbstractHttpConfigurer for reactive applications.

In my use case, we have an internal library that implements our own authentication conventions, and that is used by 10s of internal applications. One of its goals is to require the least amount of configuration possible, while still allowing some flexibility to applications.

Internally that library has servlet filters, that are automatically added to spring-security's filter chain. That is achieved through a spring.factories + a subclass of AbstractHttpConfigurer.

For reactive applications, the solution currently has been to move this configuration to the application itself (simplified through a kotlin extension function on ServerHttpSecurity).

An alternative would be to register the Bean for SecurityWebFilterChain from the library via spring-boot autoconfiguration. But then that would limit the application's flexibility, and/or would be implicitly disabled if the application registered that bean itself.