Gee Squid 7 se geauthentiseerde gebruikernaam aan ’n ICAP-diens deur

’n ICAP-diens kan die geauthentiseerde identiteit ontvang wat Squid ken, maar beide kante moet ooreenkom oor hoe daardie identiteit oorgedra word. Om net ’n opskrif te noem, aktiveer nie die deurgee van die gebruikernaam nie.

Vir ’n bestaande Squid 7-opstelling met ICAP-ondersteuning en kliëntauthentisering kan die betrokke instellings wees:

adaptation_send_username on
icap_client_username_header X-Authenticated-User
icap_client_username_encode off

Dit vul die bestaande ICAP-diens, aanpassingsreëls en proxy-toegangskonfigurasie aan. Dit skep nie authentisering of ’n aanpassingsdiens nie.

Pas by die diens se invoer

Squid se verstek-gebruikernaamopskrif is X-Client-Username. As die adapter X-Authenticated-User verwag, verander Squid se gekonfigureerde naam soos hierbo of stel die adapter in om die verstek te lees. Opskrifname word volgens HTTP se hoofletter-onsensitiewe reëls vergelyk.

Die enkodering moet ook ooreenstem. Met icap_client_username_encode geaktiveer, enkodeer Squid die waarde in Base64. Die diens moet daardie voorstelling dekodeer eerder as om dit as ’n ander gebruikernaam te behandel.

Dit is metadata oor die ICAP-uitruiling tussen Squid en sy diens. Dit is nie ’n opdrag om ’n gebruikersidentiteits-opskrif aan elke bestemmingswebwerf te stuur nie.

As die diens steeds ’n IP-adres rapporteer

Bevestig dat die transaksie werklik ’n geauthentiseerde gebruikernaam by Squid het, dat die deurgee van die gebruikernaam geaktiveer is en dat die diens die gekonfigureerde opskrif lees. ’n Adapter se terugval na ’n kliëntadres bewys nie dat Squid-verifikasie misluk het nie; die oordrag self kan ontbreek of verkeerd benoem wees.

Vertrou hierdie identiteit slegs oor die beheerde pad tussen Squid en die adapter. Hierdie riglyne is weergawe-spesifiek: die konfigurasieverwysing lys hulle vir Squid 7 en vroeëre reekse, en merk hulle as onbeskikbaar in Squid 8.