Protokol na PROXY ng Squid: pagkatiwalaan ang nagpadala bago ang mga pagsusuri sa pag-access ng HTTP

Gamitin ang proxy_protocol_access upang pagkatiwalaan ang relay na naghahatid ng metadata, hindi upang pumili ng pinapayagang web site. Sa Squid 5–7, ang pagsusuri ay tumatakbo isang beses pagkatapos ng TCP setup sa isang require-proxy-header listener, bago iproseso ang mga header ng kahilingang HTTP:

acl trusted_relay src 192.0.2.20/32
http_port 3128 require-proxy-header
proxy_protocol_access allow trusted_relay
proxy_protocol_access deny all

Palitan ang halimbawang address ng relay at limitahan ang pag-access sa network sa listener na ito. Sa yugtong ito sinusuri ng Squid ang aktwal na kapares na TCP bago tanggapin ang ibinigay na metadata. Pagkatapos ng pagtanggap, ginagamit nito ang inaangking address ng client para sa mga susunod na pagsusuri ng ACL at pag-log. Ang pagkatiwalaan ang relay batay sa inaangking address ng client ay magbabaligtad sa pagkakasunod-sunod na iyon.

Itabi ang http_access para sa mga susunod na pahintulot sa pinagmulan ng client at destinasyon. Ang pagtanggap ng metadata ay hindi nagpapahintulot ng pag-access sa web site, at ang ACL ng destinasyong domain ay hindi makasasagot sa naunang tanong tungkol sa pagtitiwala sa nagpadala.

Dapat magkasundo ang nagpadala at tumatanggap sa isang sinusuportahang bersyon ng protocol na PROXY. Ang ordinaryong HTTP client ay hindi makakagamit ng listener na ito na may mandatoryong prefix bilang karaniwang proxy endpoint. Kung kailangan ang dalawang anyo, sadyang gumamit ng magkahiwalay na endpoint sa halip na duplihin ang parehong address ng pakikinig at port.

Ang pinagkakatiwalaang relay ay makakaimpluwensya sa awtorisasyong batay sa address sa pamamagitan ng ibinibigay nitong pagkakakilanlan ng client. Ibigay lamang ang kakayahang iyon sa inilaan na tagapamagitan.