Interception ng Squid kumpara sa hayagang proxy authentication
Ipaliwanag kung bakit hindi basta maidaragdag ang ordinaryong hayagang proxy authentication sa listener ng interception ng Squid.
Alam ng kliyente ng hayagang proxy na kausap nito ang isang proxy. Ang na-intercept na browser ay nag-aakalang kumonekta ito sa website. Ang pagkakaibang iyon ang sentro ng authentication.
Ang karaniwang proxy authentication ay gumagamit ng hamon ng proxy at tugon ng awtorisasyon ng proxy. Ang kliyenteng hindi pumili ng proxy ay hindi dapat magpadala nang basta-basta ng mga kredensyal ng proxy sa di-inaasahang tagapamagitan.
Kaya hindi sinusuportahan ng patnubay sa interception ng Squid ang basta pagsasama ng proxy_auth sa mode ng interception. Hindi binabago ng gumaganang helper ng Basic authentication ang iniisip ng browser na remote endpoint.
Kung kailangan ng mga nakilalang user ng karaniwang authenticated na forward proxy, i-configure nang hayagan ang mga kliyente, direkta man o sa pamamagitan ng angkop na pinamamahalaang proxy configuration. Panatilihing hiwalay ang listener na iyon at ang patakaran nito sa authentication mula sa listener ng interception.
Ang portal ng authentication, sistema ng pagkakakilanlan sa antas ng network, o kaayusan ng interception ng TLS ay ibang disenyo na may ibang pangangailangan sa tiwala at deployment. Hindi ito isang linyang pag-aayos para sa nawawalang palitan ng hayagang proxy.
Huwag lutasin ang kawalan ng prompt sa pamamagitan ng paggawa sa na-intercept na serbisyo na pampubliko o pagpayag sa bawat kliyente. Magpasya muna kung ang pangangailangan ay hayagang user authentication o interception ng trapikong hindi kailanman na-configure para sa proxy. Magkaiba ang palagay na kailangan ng dalawa.