-
Notifications
You must be signed in to change notification settings - Fork 6.1k
Closed
Labels
in: oauth2An issue in OAuth2 modules (oauth2-core, oauth2-client, oauth2-resource-server, oauth2-jose)An issue in OAuth2 modules (oauth2-core, oauth2-client, oauth2-resource-server, oauth2-jose)type: enhancementA general enhancementA general enhancement
Milestone
Description
Related to #7353 (comment)
ServletBearerExchangeFilterFunction
consults the SecurityContextHolder
directly when looking up the current Authentication
. This is because it was initially designed to only read from the main thread.
This is limiting, however, in situations where the Authentication
may be needed off of the main thread. Consider the toy example below:
ServletBearerExchangeFilterFunction bearer = new ServletBearerExchangeFilterFunction();
WebClient webClient = WebClient.builder()
.filter((request, next) -> Mono.deferWithContext(ctx -> next.exchange(request)))
.filter(bearer)
.build();
return webClient.get()
.uri("https://endpoint.example.org")
.retrieve()
.bodyToMono(String.class)
.timeout(Duration.ofMillis(10000))
.retry(3, TimeoutException.class::isInstance)
.block();
With this setup, the ServletBearerExchangeFilterFunction
will not be executed on the main thread, meaning that SecurityContextHolder
will not be available.
ServletBearerExchangeFilterFunction
could be enhanced, though, by introducing a Hooks.onLastOperator
that adds the Authentication
to the reactor context so that more complex scenarios like the above work.
Metadata
Metadata
Assignees
Labels
in: oauth2An issue in OAuth2 modules (oauth2-core, oauth2-client, oauth2-resource-server, oauth2-jose)An issue in OAuth2 modules (oauth2-core, oauth2-client, oauth2-resource-server, oauth2-jose)type: enhancementA general enhancementA general enhancement