Simplify applying a strategy to requests from WebTestClient and WebTestClient [SPR-15691] #20250
Description
Rob Winch opened SPR-15691 and commented
Description
With the changes from #20216 modifying a request with a strategy (i.e. ExchangeFilterFunction) becomes 3 statements instead of a single one. For example, we use to have:
webClient
.filter(basicAuthentication("user","password))
...
now the code is
webClient
.mutate()
.filter(basicAuthentication("user","password))
.build()
...
It would be ideal to make this a single statement again.
Solution Ideas
Combining Methods
One idea would be to provide a single method that accepts an ExchangeFilterFunction and invokes all three methods.
webClient
// shortcut for mutate, filter, build
.with(basicAuthentication("user","password))
...
ClientRequest attributes
Another (improved) approach would be to allow ClientRequest to have some concept of attributes. Perhaps something like:
webClient
.with( requestAttrs -> { .. })
...
This would allow the ExchangeFilterFunction to leverage the requestAttrs and thus remain stateless.
This approach improves usability in regards to if an ExchangeFilterFunction needed some values that were always reused. Currently (and in the past) we would need to do something like:
webClient
.filter(oauth(someBeanThatIsConstant, a1, b1,...))
...
webClient
.filter(oauth(someBeanThatIsConstant, a2, b2,...))
...
You can see that this is a burden on the user to have to provide someBeanThatIsConstant for every request. With the above approach the someBeanThatIsConstant can be injected into an ExchangeFilterFunction that is global and the requestAttrs would provide values that change.
webClient = ...
.filter(oauth(aBeanThatIsConstant))
...
webClient
.with( requestAttrs -> { ... } )
...
webClient
// here oauth is just a static method provided by Spring Security that creates
// a consumer that does the same thing as above
.with( oauth(a1,a2) )
...
This approach also means we can make additional requests in the ExchangeFilterFunction using the ExchangeFunction without worrying about another ExchangeFilterFunction adding something that is isn't desirable to the request. For example, currently if a user makes an HTTP basic request and we want to do something inside another ExhangeFunction that makes a request, the ExchangeFunction passed in would automatically populate HTTP Basic on the new request which is not necessarily desirable.
With ClientRequest attributes the attributes would not be populated on this additional request so the ExchangeFunction would not add the basic auth headers.
Affects: 5.0 RC3
Issue Links:
- Ordering of WebClient.filter(s) [SPR-15657] #20216 Ordering of WebClient.filter(s)
Referenced from: commits 74b4c02