Preemptivní Basic autentizace proxy pro známý koncový bod
Rozhodněte, kdy se preemptivní Basic autentizace proxy hodí pro pevný koncový bod, a nedopusťte, aby se toto rozhodnutí stalo pravidlem pro přihlašovací údaje na libovolných trasách.
Klient, který čeká na výzvu, počká, až se proxy zeptá. Preemptivní Basic klient už zná vybraný koncový bod a pošle údaje v prvním vhodném požadavku. Odstranění této výměny může být užitečné. Pořád je to ale rozhodnutí o tom, kam heslo jde.
Poznejte koncový bod dřív než optimalizaci
Pevná privátní proxy se známou zásadou autentizace je jasnější případ než směrovací vrstva, která může zvolit neznámého prostředníka. Svažte účet s očekávanou identitou proxy a protokolem. Nestavějte obecný callback, který na každou výzvu odpovídá jedním firemním heslem.
Basic nese base64 reprezentaci účtu, ne šifrovaný důkaz. TLS k naslouchajícímu proxy je samostatná volba spojení od HTTPS relace webu. HTTPS tunel webu zpětně nechrání Basic údaje odeslané po nešifrovaném spojení klient–proxy. Privátní LAN je místo, ne vlastnost šifrování.
Držte mechanismus konkrétní
Preemptivní Basic není univerzální zkratka pro Digest, NTLM ani Negotiate. Tyto mechanismy mají vlastní požadavky na výměnu. Klient, který zjistí podporované schémy, může oprávněně provést další transakce.
Použijte rozhraní pro autentizaci proxy zvolené knihovny a potom zkontrolujte skutečné schéma a rozsah. Nastavení předběžné autentizace cíle nemusí řídit handshake s proxy. Existující autentizované spojení také může skrýt, zda by nové spojení provedlo výzvu.
Porovnejte celou operaci: počet výměn, dobu dokončení, požadovanou ochranu přenosu a chování při změně proxy. Čistší log je užitečný jen tehdy, pokud se aplikace stále autentizuje u zamýšleného prostředníka a zastaví se, když takové uspořádání nelze navázat.