Squid kaj duoblaj salutnomoj trans LDAP-adresaroj

Se du sendependaj adresaroj ambaŭ enhavas alex, la prokurilo bezonas elekton de adresaro antaŭ ol kontroli pasvorton. Provado unue de A kaj poste de B kaŝas tiun elekton ene de la aŭtentiga malsukceso kaj povas konfuzi neatingeblan adresaron kun rifuzita sekreto.

Du aranĝoj povas igi la identecon eksplicita:

• Kvalifikita saluto. Nomo kiel [email protected] elektas per dissendilo fiksan adresaron difinitan de administranto. Konservu la kvalifikitan identecon por rajtigo kaj protokolado. Ne transformu sufikson liveritan de kliento en arbitran adreson de LDAP-servilo.
• Stabila fidata petokunteksto. Auskultanto aŭ alia subtenata kunteksto elektas la adresaron. Difinu, kio okazas, kiam persono migras aŭ uzas alian auskultanton; reta loko ne estas persona identeco.

Replikaĵoj de unu adresaro estas aliaj: ili kunhavas identecan nomspacon. Neligitaj adresaroj ne fariĝas replikaĵoj ĉar ambaŭ uzas LDAP.

Akkordu la kaŝmemoran ŝlosilon de legitimaĵoj de Squid kun la elekto de la helpanto. La referenco auth_param priskribas key_extras por transdoni plian kuntekston kaj inkluzivi ĝin en la kaŝmemoran ŝlosilon, inkluzive de la kazo de identaj nomoj distingitaj per la auskulta pordo. La helpanto devas kompreni la pliampleksigitan enigon, kaj la elektita makroo devas esti disponebla ĉe tiu aŭtentiga etapo.

Preferu stabilan kuntekston. Ofte ŝanĝiĝanta klienta IP povas multobligi kaŝmemorajn identecojn kaj ŝanĝi regilojn, kiuj atendas unu uzanto-identecon.

Difinu aparte nekonatan adresaron, nekonatan konton, rifuzitan pasvorton kaj neatingeblan adresaron. La konto de North ne rajtas silente fariĝi la Alex de South, kiam North ne estas atingebla. Tenu tiujn rezultojn distingeblaj en protokoloj sen registri pasvortojn.