Testi proksilajn akreditaĵojn: sukceso de peto kontraŭ freŝa validigo
Uzu kontrolatan celon, poste distingi permesitan peton de freŝa kontrolo de la donita proksila pasvorto.
Peto sukcesanta tra proksio pruvas, ke tiu operacio estis permesita. Ĝi eble ne pruvas, ke la pasvorto estis kontrolita denove: la celo povas esti esceptita, aŭ la konekto jam aŭtentikiĝis.
Por operacia kontrolo uzu vian kontrolatan finpunkton kun konata malgranda respondo kaj alirpolitiko, kiun la konto devus plenumi:
curl --proxy http://proxy.example:8080 --proxy-anyauth --proxy-user 'USER:PROXY_PASSWORD' https://probe.example/statusLa finpunkto kaj konto estas lokokupiloj. Ĉi tiuj estas peraj akreditaĵoj, apartaj de iu ajn ensaluto ĉe la celo.
Tenu la respondan stadion kaj la defion kune. 407 povas komenci aŭ daŭrigi intertraktadon, raporti ne subtenatajn metodojn aŭ rifuzi konton. 403 povas indiki politikan rifuzon, kaj posta reteja eraro povas sekvi sukcesan proksilan ensaluton.
Por freŝa konta validigo uzu la subtenatan kontokontrolon de la funkciiganto aŭ protokolojn de aŭtentikigita identeco. En via propra proksio, malantaŭaj pruvoj povas distingi realan validigon de anonime permesita peto. Dum pasvortaj ŝanĝoj, inkluzivu la kaŝmemoran validigan fenestron kiam vi decidas, ĉu la malnova akreditaĵo devus esti ĉesinta funkcii. Por Squid 6.13 Basic, credentialsttl regas validigan kaŝmemoran fenestron.