En proxypålogging tilhører transportens legitimasjonsleverandør. Med Spring 6 og Apache HttpClient 5 begrenser du den kontoen til mellomleddet:

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 leverer verdiene proxyUser og proxyPassword og eier livssyklusen til HTTP-klienten. Gjenbruk rest for arbeidsbelastningen i stedet for å bygge en ny standardmal på kallstedet.

AuthScope begrenser hvor disse opplysningene er gyldige. Eksemplet leverer vanlige brukernavn/passord-opplysninger; navnet BasicCredentialsProvider tvinger ikke hver utfordring til å bruke HTTP Basic-skjemaet.

Med en HTTPS-destinasjon kan transporten svare på en proxyutfordring under CONNECT, før programmets krypterte HTTP-forespørsel finnes. En generisk destinasjonsinterceptor som legger til Proxy-Authorization er ikke likeverdig med den forhandlingen.

Konfigurer enhver destinasjonskonto separat. Hvis proxyen fortsatt avviser forespørselen, behold det annonserte autentiseringsskjemaet samt den effektive verten og porten. Opplysninger begrenset til et annet endepunkt vil ikke samsvare bare fordi passordet er riktig.

Relaterte artikler