Förebyggande Basic-proxyautentisering för en känd ändpunkt
Avgör när förebyggande Basic-proxyautentisering passar för en fast ändpunkt, och låt inte det beslutet bli en legitimationsregel för godtyckliga rutter.
En klient som väntar på en utmaning väntar på att proxyn ska fråga. En förebyggande Basic-klient känner redan till den valda ändpunkten och skickar legitimationen med sin första tillämpliga begäran. Att ta bort det utbytet kan vara användbart. Det är fortfarande ett beslut om vart ett lösenord tar vägen.
Känn till ändpunkten före optimeringen
En fast privat proxy med känd autentiseringspolicy är ett tydligare fall än ett routningslager som kan välja en okänd mellanhand. Bind kontot till den förväntade proxyidentiteten och protokollet. Bygg inte en generisk callback som svarar på varje utmaning med ett enda företagslösenord.
Basic bär en base64-representation av kontot, inte ett krypterat bevis. TLS till proxyllyssnaren är ett separat anslutningsval skilt från webbplatsens HTTPS-session. Webbplatsens HTTPS-tunnel skyddar inte i efterhand en Basic-legitimation som skickats över en okrypterad klient-till-proxy-anslutning. Ett privat LAN är en plats, inte en krypteringsegenskap.
Håll mekanismen specifik
Förebyggande Basic är inte en universell genväg för Digest, NTLM eller Negotiate. Dessa mekanismer har egna utbyteskrav. En klient som upptäcker stödda scheman får lagligen utföra extra transaktioner.
Använd det valda bibliotekets proxyautentiseringsgränssnitt och granska sedan det effektiva schemat och omfattningen. En inställning för förhandsautentisering av destinationen styr kanske inte proxy-handskakningen. En befintlig autentiserad anslutning kan också dölja om en ny anslutning skulle utföra en utmaning.
Jämför hela operationen: antal utbyten, slutförandetid, nödvändigt transportskydd och beteendet när proxyn ändras. En renare logg är bara användbar om applikationen fortfarande autentiserar mot den avsedda mellanhanden och stoppar när den ordningen inte kan upprättas.