Føregripande Basic-proxyautentisering for eit kjent endepunkt
Avgjer når føregripande Basic-proxyautentisering passar for eit fast endepunkt, og la ikkje den avgjerda bli ein legitimasjonsregel for vilkårlege ruter.
Ein klient som ventar på ei utfordring, ventar på at proxyen spør. Ein føregripande Basic-klient kjenner allereie det valde endepunktet og sender legitimasjonen med den første relevante førespurnaden sin. Å fjerna den utvekslinga kan vera nyttig. Det er framleis ei avgjerd om kvar eit passord hamnar.
Kjenn endepunktet før optimaliseringa
Ein fast privat proxy med kjend autentiseringspolicy er eit klarare tilfelle enn eit rutingslag som kan velja ein ukjend mellommann. Bind kontoen til forventa proxyidentitet og -protokoll. Ikkje bygg ein generisk callback som svarar kvar utfordring med eitt bedriftspassord.
Basic ber ein base64-representasjon av kontoen, ikkje eit kryptert prov. TLS til proxylyttaren er eit eige tilkoplingsval skilt frå HTTPS-økta til nettstaden. HTTPS-tunnelen til nettstaden vernar ikkje i ettertid ein Basic-legitimasjon send over ei ukryptert klient-til-proxy-tilkopling. Eit privat LAN er ein stad, ikkje ein krypteringseigenskap.
Hald mekanismen spesifikk
Føregripande Basic er ikkje ein universell snarveg for Digest, NTLM eller Negotiate. Desse mekanismane har eigne utvekslingskrav. Ein klient som oppdagar støtta skjema, kan lovleg utføra ekstra transaksjonar.
Bruk proxyautentiseringsgrensesnittet til det valde biblioteket, og undersøk deretter det effektive skjemaet og omfanget. Ei innstilling for førehandsautentisering av destinasjonen styrer kanskje ikkje proxy-handtrykket. Ei eksisterande autentisert tilkopling kan òg skjula om ei ny tilkopling ville utføra ei utfordring.
Samanlikn heile operasjonen: talet på utvekslingar, fullføringstid, naudsynt transportvern og åtferda når proxyen endrar seg. Ein reinare logg er berre nyttig om applikasjonen framleis autentiserer mot den tiltenkte mellommannen og stoppar når den ordninga ikkje kan etablerast.