Զննարկիչը հասնում է ինքնության մատակարարին, ապա մուտքը ձախողվում է, երբ հավելվածը փոխանակում է վերադարձված թույլտվության կոդը։ Այդ փոխանակումը հավելվածի սերվերից ելքային հարցում է՝ իր սեփական HTTP հաճախորդով։

Spring Security 6.5-ում հասանելի RestClient-ի վրա հիմնված API-ի համար թույլտվության կոդի թոքենի պատասխանի հաճախորդին տվեք պրոքսին հասկացող հարցումների գործարան։

SimpleClientHttpRequestFactory factory = new SimpleClientHttpRequestFactory();
factory.setProxy(new java.net.Proxy(
    java.net.Proxy.Type.HTTP,
    new java.net.InetSocketAddress("proxy.example", 8080)));
factory.setConnectTimeout(5000);
factory.setReadTimeout(15000);

RestClient tokenHttp = RestClient.builder()
    .requestFactory(factory)
    .messageConverters(converters -> {
        converters.clear();
        converters.add(new FormHttpMessageConverter());
        converters.add(new OAuth2AccessTokenResponseHttpMessageConverter());
    })
    .defaultStatusHandler(new OAuth2ErrorResponseErrorHandler())
    .build();

RestClientAuthorizationCodeTokenResponseClient tokenClient =
    new RestClientAuthorizationCodeTokenResponseClient();
tokenClient.setRestClient(tokenHttp);

Փոխարկիչի և սխալների մշակիչի դասերը պահպանում են Spring Security-ի փաստաթղթավորված թոքենի հարցման վարքը։ Միայն անկապ JSON API-ի համար կարգավորված ընդհանուր RestClient-ը համարժեք փոխարինում չէ։

Միացրեք նույն tokenClient-ը գոյություն ունեցող անվտանգության կարգավորմանը։

http.oauth2Login(login -> login
    .tokenEndpoint(token -> token
        .accessTokenResponseClient(tokenClient)));

Սրանք կարգավորման բեկորներ են հավելվածի համար, որն արդեն ունի իր հաճախորդի գրանցումը և SecurityFilterChain-ը։ Նրանք ընտրում են առանց նույնականացման HTTP պրոքսի. հավատարմագրեր պահանջող պրոքսին անհրաժեշտ է ընտրված տրանսպորտի համապատասխան նույնականացման կարգավորում։ Թույլատրված հանրային երթուղու վրա հանրությանը հասանելի HTTPS թոքենի վերջնակետի համար HTTP պրոքսիների ցանկից HTTP գրառումը կարող է լրացնել այդ հաշիվ չունեցող պրոքսիի հասցեն։

Պրոքսիի հոսթը առանձնացրեք նրա պորտից և URL սխեմայից։ Ինքնության մատակարարի թոքենի URI-ն թողեք որպես նպատակակետ։ Օրինակը չի փոխարինում սերտիֆիկատի վավերացմանը։

Հետագա հարցումներին անհրաժեշտ է իրենց սեփական սեփականության ստուգում։ UserInfo-ի ստացումը, թարմացման թոքենի փոխանակումները, client-credentials շնորհները և պաշտպանված API կանչերը կարող են օգտագործել այլ հաճախորդի օբյեկտներ։ Կարգավորեք համապատասխան աջակցվող հաճախորդը, երբ այդ գործողությունը նույնպես երթուղի է պահանջում։ Spring Security 6.5-ի ռեակտիվ client_credentials հոսքի համար առանձին կարգավորեք ռեակտիվ թոքենի հաճախորդը և նրա շնորհի մատակարարը։

OAuth2RestTemplate և AccessTokenProvider օգտագործող հին օրինակները պատկանում են ավելի հին Spring Security OAuth նախագծին։ Կոդը հարմարեցնելուց առաջ ընտրեք տեղադրված հավելվածի օգտագործած API-ն. այդ օբյեկտները մի խառնեք այս կարգավորմանը։

Առնչվող հոդվածներ