En klient kan autentisera sig mot en Apache-vidarebefordringsproxy med ett konto, medan Apache autentiserar sig mot en överordnad proxy med ett annat:

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

För ett fast konto för överordnad proxy på httpd 2.4.59 eller senare accepterar ProxyRemote ett tredje argument:

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

Detta kompletterar den befintliga åtkomststyrda vidarebefordringsproxykonfigurationen, till exempel en privat lyssnare som kräver både klient-IP och proxyinloggning. Kontot tillhör den valda överordnade proxyn. Skydda konfigurationen som innehåller det och välj den matchningsomfattning som utrullningen kräver.

Apache skickar dessa Basic-uppgifter i förväg, utan att först vänta på en utmaning. Det gör transport och kontopolitik för den överordnade anslutningen viktiga; webbplatsens senare HTTPS-session skyddar inte i sig ett klartext-HTTP-hopp till den överordnade proxyn.

När samma inkommande konto bör fortsätta

Apache förbrukar normalt den proxyautentisering som är riktad till honom själv. Miljöinställningen proxy-chain-auth tillåter i stället att klientens proxyuppgifter skickas vidare till nästa proxy:

SetEnv proxy-chain-auth On

Detta passar bara för en avsiktligt delad autentiseringskedja. Den skickar det inkommande kontomaterialet vidare; den hittar inte på ett annat användarnamn och lösenord för den överordnade proxyn.

Med ProxyRemotes uttryckliga uppgiftsargument har proxy-chain-auth ingen verkan. Välj källan till uppgifterna medvetet i stället för att stapla båda inställningarna i hopp om att lösenordet som fungerar väljs.

Dessa mekanismer autentiserar proxyhopp. Authorization-huvudet för en målwebbplats är fortfarande ett separat utbyte.

Relaterade artiklar