RestTemplate-ის პროქსის სერტიფიკატების შეზღუდვა HttpClient 5-ით

პროქსიში შესვლა ტრანსპორტის სერტიფიკატების მომწოდებელს ეკუთვნის. Spring 6-ისა და Apache HttpClient 5-ის შემთხვევაში, შეზღუდეთ ეს ანგარიში შუამავალზე:

var proxy = new org.apache.hc.core5.http.HttpHost(
    "http", "proxy.example", 8080);
var credentials = new org.apache.hc.client5.http.impl.auth
    .BasicCredentialsProvider();
credentials.setCredentials(
    new org.apache.hc.client5.http.auth.AuthScope(proxy),
    new org.apache.hc.client5.http.auth.UsernamePasswordCredentials(
        proxyUser, proxyPassword.toCharArray()));

var http = org.apache.hc.client5.http.impl.classic.HttpClients.custom()
    .setProxy(proxy)
    .setDefaultCredentialsProvider(credentials)
    .build();
var factory = new org.springframework.http.client
    .HttpComponentsClientHttpRequestFactory(http);
var rest = new org.springframework.web.client.RestTemplate(factory);

აპლიკაცია აწვდის proxyUser და proxyPassword მნიშვნელობებს და ფლობს HTTP კლიენტის სასიცოცხლო ციკლს. სამუშაო დატვირთვისთვის ხელახლა გამოიყენეთ rest, ნაცვლად იმისა, რომ გამოძახების ადგილას კიდევ ერთი ნაგულისხმევი შაბლონი ააგოთ.

AuthScope ზღუდავს, სად არის ეს სერტიფიკატები მოქმედი. მაგალითი აწვდის ჩვეულებრივ მომხმარებლის სახელის/პაროლის სერტიფიკატებს; სახელი BasicCredentialsProvider არ ავალდებულებს ყველა გამოწვევას გამოიყენოს HTTP Basic სქემა.

HTTPS დანიშნულებისას ტრანსპორტს შეუძლია პროქსის გამოწვევაზე პასუხი გასცეს CONNECT-ის დროს, სანამ აპლიკაციის დაშიფრული HTTP მოთხოვნა არსებობს. ზოგადი დანიშნულების ინტერცეპტორი, რომელიც ამატებს Proxy-Authorization-ს, არ უდრის ამ მოლაპარაკებას.

ნებისმიერი დანიშნულების ანგარიში ცალკე დააკონფიგურირეთ. თუ პროქსი კვლავ უარყოფს მოთხოვნას, შეინარჩუნეთ მის მიერ გამოცხადებული ავთენტიფიკაციის სქემა და რეალური ჰოსტი და პორტი. სხვა ბოლო წერტილისთვის შეზღუდული სერტიფიკატი არ დაემთხვევა მხოლოდ იმიტომ, რომ პაროლი სწორია.