Apache ProxyRemote-legitimasjon kontra proxy-chain-auth

En klient kan autentisere seg mot en Apache-videresendingsproxy med én konto, mens Apache autentiserer seg mot en overordnet proxy med en annen:

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

For en fast konto for overordnet proxy på httpd 2.4.59 eller nyere godtar ProxyRemote et tredje argument:

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

Dette utfyller den eksisterende tilgangskontrollerte videresendingsproxy-konfigurasjonen, for eksempel en privat lytter som krever både klient-IP og proxy-innlogging. Kontoen tilhører den valgte overordnede proxyen. Beskytt konfigurasjonen som inneholder den, og velg samsvarsomfanget som utrullingen krever.

Apache sender denne Basic-legitimasjonen på forhånd, uten først å vente på en utfordring. Det gjør transport og kontopolitikk for den overordnede forbindelsen viktig; nettstedets senere HTTPS-økt beskytter ikke i seg selv et klartekst-HTTP-hopp til den overordnede proxyen.

Når den samme innkommende kontoen bør videreføres

Apache bruker normalt proxy-autentisering som er adressert til seg selv. Miljøinnstillingen proxy-chain-auth tillater i stedet å sende klientens proxy-legitimasjon videre til neste proxy:

SetEnv proxy-chain-auth On

Dette passer bare for en bevisst delt autentiseringskjede. Den sender det innkommende kontomaterialet videre; den finner ikke opp et annet brukernavn og passord for den overordnede proxyen.

Med ProxyRemotes eksplisitte legitimasjonsargument har proxy-chain-auth ingen virkning. Velg legitimasjonskilden bevisst i stedet for å legge begge innstillingene oppå hverandre i håp om at passordet som virker, blir valgt.

Disse mekanismene autentiserer proxy-hopp. Authorization-headeren til et målområde forblir en egen utveksling.