En proxyinloggning tillhör transportens uppgiftsleverantör. Med Spring 6 och Apache HttpClient 5 begränsar du det kontot till mellanhanden:

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

Programmet tillhandahåller värdena proxyUser och proxyPassword och äger HTTP-klientens livscykel. Återanvänd rest för arbetsbelastningen i stället för att bygga en ny standardmall på anropsplatsen.

AuthScope begränsar var dessa uppgifter är giltiga. Exemplet tillhandahåller vanliga användarnamn/lösenordsuppgifter; namnet BasicCredentialsProvider tvingar inte varje utmaning att använda HTTP Basic-schemat.

Med en HTTPS-destination kan transporten svara på en proxyutmaning under CONNECT, innan programmets krypterade HTTP-begäran finns. En generisk destinationsinterceptor som lägger till Proxy-Authorization är inte likvärdig med den förhandlingen.

Konfigurera varje destinationskonto separat. Om proxyn fortfarande avvisar begäran, behåll det annonserade autentiseringsschemat samt den effektiva värden och porten. Uppgifter som är begränsade till en annan slutpunkt matchar inte bara för att lösenordet är korrekt.

Relaterade artiklar