Klijent koji prvo čeka izazov čeka da proxy pita. Preemptivni Basic klijent već zna odabranu krajnju točku i šalje vjerodajnicu u prvom primjenjivom zahtjevu. Uklanjanje te razmjene može biti korisno. Ipak, to ostaje odluka o tome kamo lozinka ide.

Upoznajte krajnju točku prije optimizacije

Fiksni privatni proxy s poznatom politikom autentifikacije jasniji je slučaj od sloja usmjeravanja koji može odabrati nepoznatog posrednika. Vežite račun uz očekivani identitet proxyja i protokol. Ne gradite generički callback koji na svaki izazov odgovara jednom korporativnom lozinkom.

Basic nosi base64 prikaz računa, a ne šifrirani dokaz. TLS do proxy poslužitelja je odvojen izbor veze od HTTPS sesije web stranice. HTTPS tunel stranice ne štiti retroaktivno Basic vjerodajnicu poslanu preko nešifrirane veze klijent–proxy. Privatni LAN je lokacija, a ne svojstvo šifriranja.

Držite mehanizam konkretnim

Preemptivni Basic nije univerzalni prečac za Digest, NTLM ili Negotiate. Ti mehanizmi imaju vlastite zahtjeve razmjene. Klijent koji otkrije podržane sheme može legitimno izvesti dodatne transakcije.

Koristite sučelje za autentifikaciju proxyja odabrane biblioteke, a zatim provjerite stvarnu shemu i opseg. Postavka za prethodnu autentifikaciju odredišta možda ne kontrolira proxy rukovanje. Postojeća autentificirana veza također može sakriti bi li nova veza izvela izazov.

Usporedite cijelu operaciju: broj razmjena, vrijeme završetka, potrebnu zaštitu prijenosa i ponašanje kada se proxy promijeni. Čistiji dnevnik koristan je samo ako se aplikacija još autentificira kod namjeravanog posrednika i zaustavlja kada se taj dogovor ne može uspostaviti.

Povezani članci