AuthenticationWebFilter uses the exchange object throughout its implementation. It uses it for its ServerWebExchangeMatcher, ServerAuthenticationConverter, ServerSecurityContextRepository and all its other HTTP-based collaborators.

It would be cleaner for AuthenticationWebFilter to take a ReactiveAuthenticationManagerResolver<ServerWebExchange> instead of a ReactiveAuthenticationManagerResolver<ServerHttpRequest> to align with the rest of the API.

One way to achieve this might be to add an interface like:

public interface ServerWebExchangeReactiveAuthenticationManagerResolver
        extends ReactiveAuthenticationManagerResolver<ServerWebExchange> {
}

And then add a constructor:

public AuthenticationWebFilter
        (ServerWebExchangeReactiveAuthenticationManagerResolver resolver)  {
    // ...
}

The downside here is that we'd have an interface that we would not otherwise have introduced.

Or, since this is a very new feature, it might be best to simply change the constructor parameter generic type to alleviate confusion. That is, change:

public AuthenticationWebFilter
        (ReactiveAuthenticationManagerResolver<ServerHttpRequest> resolver)  {
    // ...
}

to

public AuthenticationWebFilter
        (ReactiveAuthenticationManagerResolver<ServerWebExchange> resolver)  {
    // ...
}

And then document the change in the 5.3 release notes.

Comment From: jzheaux

After chatting a bit with @rwinch about this, I think we should do the second option. It is a new enough feature that doing so will cause the least confusion in the long term.