Foregribende Basic-proxygodkendelse til et kendt endepunkt
Afgør hvornår foregribende Basic-proxygodkendelse passer til et fast endepunkt, og lad ikke den beslutning blive en legitimationsregel for vilkårlige ruter.
En klient, der venter på en udfordring, venter på at proxyen spørger. En foregribende Basic-klient kender allerede det valgte endepunkt og sender legitimationsoplysningerne med sin første relevante anmodning. At fjerne den udveksling kan være nyttigt. Det er stadig en beslutning om, hvor en adgangskode havner.
Kend endepunktet før optimeringen
En fast privat proxy med en kendt godkendelsespolitik er et klarere tilfælde end et routinglag, der kan vælge en ukendt mellemmand. Bind kontoen til den forventede proxyidentitet og -protokol. Byg ikke et generisk callback, der besvarer hver udfordring med én virksomhedsadgangskode.
Basic bærer en base64-repræsentation af kontoen, ikke et krypteret bevis. TLS til proxyens lytter er et separat forbindelsesvalg fra webstedets HTTPS-session. Webstedets HTTPS-tunnel beskytter ikke bagudrettet en Basic-legitimation sendt over en ukrypteret klient-til-proxy-forbindelse. Et privat LAN er en placering, ikke en krypteringsegenskab.
Hold mekanismen specifik
Foregribende Basic er ikke en universel genvej til Digest, NTLM eller Negotiate. De mekanismer har deres egne udvekslingskrav. En klient, der opdager understøttede skemaer, kan legitimt udføre ekstra transaktioner.
Brug det valgte biblioteks proxygodkendelsesgrænseflade, og undersøg derefter det effektive skema og omfang. En indstilling til forhåndsgodkendelse af destinationen styrer måske ikke proxy-håndtrykket. En eksisterende godkendt forbindelse kan også skjule, om en ny forbindelse ville udføre en udfordring.
Sammenlign hele operationen: antal udvekslinger, fuldførelsestid, nødvendig transportbeskyttelse og adfærden, når proxyen skifter. En renere log er kun nyttig, hvis applikationen stadig godkender sig over for den tilsigtede mellemmand og stopper, når den ordning ikke kan etableres.