Prokura ensaluto apartenas al la akreditaĵ-provizanto de la transporto. Por Spring 6 kun Apache HttpClient 5, limigu tiun konton al la peranto:

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);

La aplikaĵo provizas la valorojn proxyUser kaj proxyPassword kaj posedas la vivciklon de la HTTP-kliento. Reuzu rest por la laborŝarĝo anstataŭ konstrui alian defaŭltan ŝablonon ĉe la alvoka loko.

AuthScope limigas, kie tiuj akreditaĵoj validas. La ekzemplo provizas ordinarajn uzantnomon/kontraŭsignon; la nomo BasicCredentialsProvider ne devigas ĉiun defion uzi la HTTP Basic-skemon.

Ĉe HTTPS-celo, la transporto povas respondi prokuran defion dum CONNECT, antaŭ ol ekzistas la ĉifrita HTTP-peto de la aplikaĵo. Ĝenerala cel-interkaptilo, kiu aldonas Proxy-Authorization, ne samvaloras al tiu intertraktado.

Konfiguru ĉiun celan konton aparte. Se la prokuro ankoraŭ rifuzas la peton, konservu ĝian anoncitan aŭtentikigan skemon kaj la efektivan gastiganton kaj pordon. Akreditaĵo limigita al alia finpunkto ne kongruos nur ĉar la pasvorto estas ĝusta.

Rilataj artikoloj