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.