Apache ProxyRemote-legitimasjon kontra proxy-chain-auth

Ein klient kan autentisere seg mot ein Apache-vidareføringsproxy med éin konto, medan Apache autentiserer seg mot ein overordna proxy med ein annan:

client ── client account ── Apache ── parent account ── parent proxy

For ein fast konto for overordna proxy på httpd 2.4.59 eller nyare godtek ProxyRemote eit tredje argument:

ProxyRemote "*" "http://parent.example:3128" "parent-user:replace_with_private_password"

Dette utfyller den eksisterande tilgangskontrollerte vidareføringsproxy-konfigurasjonen, til dømes ein privat lyttar som krev både klient-IP og proxy-innlogging. Kontoen høyrer til den valde overordna proxyen. Vern konfigurasjonen som inneheld han, og vel samsvarsomfanget som utrullinga krev.

Apache sender denne Basic-legitimasjonen på førehand, utan å først vente på ei utfordring. Det gjer transport og kontopolitikk for den overordna sambindinga viktig; den seinare HTTPS-økta til nettstaden vernar ikkje i seg sjølv eit klartekst-HTTP-hopp til den overordna proxyen.

Når den same innkomande kontoen bør vidareførast

Apache brukar normalt proxy-autentisering som er adressert til han sjølv. Miljøinnstillinga proxy-chain-auth tillèt i staden å sende klienten sine proxy-legitimasjonar vidare til neste proxy:

SetEnv proxy-chain-auth On

Dette passar berre for ei medvite delt autentiseringskjede. Ho sender det innkomande kontomaterialet vidare; ho finn ikkje opp eit anna brukarnamn og passord for den overordna proxyen.

Med det eksplisitte legitimasjonsargumentet til ProxyRemote har proxy-chain-auth inga verknad. Vel legitimasjonskjelda medvite i staden for å leggje båe innstillingane oppå kvarandre i håp om at passordet som verkar, vert valt.

Desse mekanismane autentiserer proxy-hopp. Authorization-hovudet til eit målområde er framleis ei eiga utveksling.