Foregripende Basic-proxyautentisering for et kjent endepunkt
Avgjør når foregripende Basic-proxyautentisering passer for et fast endepunkt, og ikke la den beslutningen bli en legitimasjonsregel for vilkårlige ruter.
En klient som venter på en utfordring, venter på at proxyen spør. En foregripende Basic-klient kjenner allerede det valgte endepunktet og sender legitimasjonen med sin første aktuelle forespørsel. Å fjerne den utvekslingen kan være nyttig. Det er likevel en beslutning om hvor et passord havner.
Kjenn endepunktet før optimaliseringen
En fast privat proxy med kjent autentiseringspolicy er et tydeligere tilfelle enn et rutelag som kan velge en ukjent mellommann. Bind kontoen til forventet proxyidentitet og protokoll. Ikke bygg en generisk callback som besvarer hver utfordring med ett bedriftspassord.
Basic bærer en base64-representasjon av kontoen, ikke et kryptert bevis. TLS til proxylytteren er et eget tilkoblingsvalg atskilt fra nettstedets HTTPS-økt. Nettstedets HTTPS-tunnel beskytter ikke i ettertid en Basic-legitimasjon sendt over en ukryptert klient-til-proxy-tilkobling. Et privat LAN er et sted, ikke en krypteringsegenskap.
Hold mekanismen spesifikk
Foregripende Basic er ikke en universell snarvei for Digest, NTLM eller Negotiate. Disse mekanismene har egne utvekslingskrav. En klient som oppdager støttede skjemaer, kan lovlig utføre ekstra transaksjoner.
Bruk proxyautentiseringsgrensesnittet til det valgte biblioteket, og undersøk deretter det effektive skjemaet og omfanget. En innstilling for forhåndsautentisering av destinasjonen styrer kanskje ikke proxy-håndtrykket. En eksisterende autentisert tilkobling kan også skjule om en ny tilkobling ville utføre en utfordring.
Sammenlign hele operasjonen: antall utvekslinger, fullføringstid, nødvendig transportbeskyttelse og oppførselen når proxyen endres. En renere logg er bare nyttig hvis applikasjonen fortsatt autentiserer mot den tiltenkte mellommannen og stopper når den ordningen ikke kan etableres.