Kliento povas aŭtentigi sin al antaŭa prokuro de Apache per unu konto, dum Apache aŭtentigas sin al gepatra prokuro per alia:

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

Por fiksa konto de gepatra prokuro ĉe httpd 2.4.59 aŭ pli nova, ProxyRemote akceptas trian argumenton:

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

Ĉi tio kompletigas la ekzistantan alirkontrolitan antaŭprokuran agordon, ekzemple privatan aŭskultanton, kiu postulas kaj klientan IP-adreson kaj prokuran ensaluton. La konto apartenas al la elektita gepatra prokuro. Protektu la agordon, kiu enhavas ĝin, kaj elektu la kongruan amplekson postulatan de la provizado.

Apache sendas ĉi tiujn Basic-akreditaĵojn anticipe, sen unue atendi defion. Tio gravegas la transporton kaj kontan politikon de la gepatra ligo; la posta HTTPS-sesio de la retejo mem ne protektas klaran HTTP-salton al la gepatra prokuro.

Kiam la sama alvena konto devus daŭri

Apache kutime konsumas prokuran aŭtentigon adresitan al si mem. La medivariablo proxy-chain-auth anstataŭe permesas transdoni la prokurajn akreditaĵojn de la kliento al la sekva prokuro:

SetEnv proxy-chain-auth On

Ĉi tio taŭgas nur por intence komuna aŭtentiga ĉeno. Ĝi transdonas la alvenan kontan materialon antaŭen; ĝi ne elpensas alian uzantnomon kaj pasvorton por la gepatra prokuro.

Kun la eksplicita akreditaĵa argumento de ProxyRemote, proxy-chain-auth havas neniun efikon. Elektu la fonton de akreditaĵoj konscie anstataŭ tavoligi ambaŭ agordojn esperante, ke la funkcianta pasvorto estos elektita.

Ĉi tiuj mekanismoj aŭtentigas prokurajn saltojn. La Authorization-kapo de celretejo restas aparta interŝanĝo.

Rilataj artikoloj