Risurco WebClient iranta tra prokseo ankoraŭ povas malsukcesi antaŭ sia API-voko, se la akiron de ĵetono uzas alian konektilon. Por la reaktiva client_credentials-fluo de Spring Security 6.5 konektu ĉiujn tri partojn:

HttpClient route = HttpClient.create()
    .proxy(p -> p.type(ProxyProvider.Proxy.HTTP)
        .host("proxy.example").port(8080));
WebClient tokenHttp = WebClient.builder()
    .clientConnector(new ReactorClientHttpConnector(route))
    .build();

var tokens = new WebClientReactiveClientCredentialsTokenResponseClient();
tokens.setWebClient(tokenHttp);

var provider = new ClientCredentialsReactiveOAuth2AuthorizedClientProvider();
provider.setAccessTokenResponseClient(tokens);

var manager = new AuthorizedClientServiceReactiveOAuth2AuthorizedClientManager(
    registrations, authorizedClients);
manager.setAuthorizedClientProvider(provider);

tokens.setWebClient atribuas la ĵetonan HTTP-klienton; provider.setAccessTokenResponseClient atribuas ĝin al la grant-provizanto; manager.setAuthorizedClientProvider instalas tiun provizanton. Uzu ĉi tiun administrilon en la fakta OAuth-filtro aŭ authorized-client-laborfluo.

HttpClient kaj ProxyProvider estas tipoj de Reactor Netty. WebClient kaj ĝia konektilo estas tipoj de Spring WebFlux. Provizu la ekzistantan ReactiveClientRegistrationRepository kiel registrations kaj ReactiveOAuth2AuthorizedClientService kiel authorizedClients.

Ĉi tiu provizanto pritraktas client_credentials; konservu taŭgan provizantan ĉenon se aliaj grantoj necesas. La ekzemplo havas neniun proksean konton; tiu apartenus al la transporto, ne al la OAuth-client-ID/sekretaĵo. Por publika ĵetona finpunkto permesata tra publika peranto, elektu gastiganton kaj pordon el la listo de HTTP-prokseoj.

Agordu ankaŭ la konektilon de la protektita risurco kiam tiuj API-vokoj bezonas la itineron. Ĵetona sukceso kaj API-sukceso estas apartaj rezultoj.

Rilataj artikoloj