Fyrirfram Basic-proxy-auðkenning fyrir þekktan endapunkt
Ákvarðaðu hvenær fyrirfram Basic-proxy-auðkenning hentar föstum endapunkti, og láttu þá ákvörðun ekki verða að reglu um auðkenni fyrir handahófskenndar leiðir.
Biðlari sem bíður eftir áskorun fyrst bíður eftir að proxyið spyrji. Fyrirfram Basic-biðlari þekkir þegar valinn endapunkt og sendir auðkennið í fyrstu viðeigandi beiðni sinni. Að fjarlægja þau skipti getur verið gagnlegt. Það er samt ákvörðun um hvert lykilorð fer.
Þekktu endapunktinn fyrir hagræðinguna
Fast einkaproxy með þekktri auðkenningarstefnu er skýrara tilvik en leiðarvinnslulag sem gæti valið ókunnan millilið. Bindu reikninginn við vænt auðkenni proxysins og samskiptaregluna. Byggðu ekki almennt callback sem svarar hverri áskorun með einu fyrirtækjalykilorði.
Basic ber base64-framsetningu reikningsins, ekki dulritað sönnunargagn. TLS að hlustanda proxysins er sérstakt tengingarval frá HTTPS-lotunni á vefnum. HTTPS-göng vefsins vernda ekki afturvirkt Basic-auðkenni sem sent er um ódulritaða tengingu biðlara við proxy. EinkaLAN er staðsetning, ekki dulritunareiginleiki.
Haltu vélbúnaðinum skýrum
Fyrirfram Basic er ekki algild stytting fyrir Digest, NTLM eða Negotiate. Þessar aðferðir hafa sínar eigin skiptakröfur. Biðlari sem finnur studd kerfi má lögmætt framkvæma fleiri færslur.
Notaðu proxy-auðkenningarviðmót valinnar söfnunar og skoðaðu síðan raunverulegt kerfi og umfang. Stilling fyrir fyrirframauðkenningu áfangastaðar stýrir kannski ekki handabandi proxysins. Núverandi auðkennd tenging getur líka falið hvort ný tenging myndi framkvæma áskorun.
Berðu saman alla aðgerðina: fjölda skipta, lokatíma, nauðsynlega flutningsvernd og hegðun þegar proxyið breytist. Hreinna log er aðeins gagnlegt ef forritið auðkennir sig enn við fyrirhugaðan millilið og stöðvast þegar ekki er hægt að koma því fyrirkomulagi á.