’n Kliënt kan by ’n Apache-vooruitproxy met een rekening verifieer, terwyl Apache by ’n ouerproxy met ’n ander rekening verifieer:

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

Vir ’n vaste ouerproxy-rekening op httpd 2.4.59 of later aanvaar ProxyRemote ’n derde argument:

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

Dit vul die bestaande toegangsbeheerde vooruitproxy-konfigurasie aan, soos ’n private luisteraar wat beide ’n kliënt-IP en ’n proxy-aanmelding vereis. Die rekening behoort aan die gekose ouerproxy. Beskerm die konfigurasie wat dit bevat, en kies die pasomvang wat die ontplooiing vereis.

Apache stuur hierdie Basic-getuigskappe vooraf, sonder om eers op ’n uitdaging te wag. Dit maak die ouerverbinding se vervoer en rekeningbeleid belangrik; die webwerf se latere HTTPS-sessie beskerm nie self ’n ongeïnkripteerde HTTP-stap na die ouerproxy nie.

Wanneer dieselfde inkomende rekening moet voortgaan

Apache verbruik gewoonlik proxy-verifikasie wat aan homself gerig is. Die omgewingsinstelling proxy-chain-auth laat eerder toe dat die kliënt se proxy-getuigskappe na die volgende proxy deurgegee word:

SetEnv proxy-chain-auth On

Dit is slegs gepas vir ’n doelbewus gedeelde verifikasieketting. Dit gee die inkomende rekeningmateriaal aan; dit skep nie ’n ander ouerproxy-gebruikersnaam en -wagwoord nie.

Met ProxyRemote se eksplisiete getuigskap-argument het proxy-chain-auth geen effek nie. Kies die getuigskapbron doelbewus eerder as om beide instellings te stapel in die hoop dat die wagwoord wat werk, gekies sal word.

Hierdie meganismes verifieer proxy-stappe. ’n Bestemmingswebwerf se Authorization-opskrif bly ’n aparte uitruiling.

Verwante artikels