Voorkomende Basic-proxyverifikasie vir 'n bekende eindpunt

'n Kliënt wat eers op 'n uitdaging wag, wag tot die proxy vra. 'n Voorkomende Basic-kliënt ken reeds die gekose eindpunt en stuur die geloofsbrief met sy eerste toepaslike versoek. Om daardie uitruiling te verwyder kan nuttig wees. Dit bly 'n besluit oor waar 'n wagwoord heen gaan.

Ken die eindpunt voor die optimalisering

'n Vaste private proxy met 'n bekende verifikasiebeleid is 'n duideliker geval as 'n routeringslaag wat 'n onbekende tussenganger kan kies. Bind die rekening aan die verwagte proxy-identiteit en -protokol. Moenie 'n generiese callback bou wat elke uitdaging met een maatskappywagwoord beantwoord nie.

Basic dra 'n base64-voorstelling van die rekening, nie 'n versleutelde bewys nie. TLS na die proxy-luisteraar is 'n aparte verbindingskeuse van die webwerf se HTTPS-sessie. Die webwerf se HTTPS-tonnel beskerm nie terugwerkend 'n Basic-geloofsbrief wat oor 'n onversleutelde kliënt-tot-proxy-verbinding gestuur word nie. 'n Private LAN is 'n ligging, nie 'n versleutelingseienskap nie.

Hou die meganisme spesifiek

Voorkomende Basic is nie 'n universele kortpad vir Digest, NTLM of Negotiate nie. Daardie meganismes het hul eie uitruilvereistes. 'n Kliënt wat ondersteunde skemas ontdek, kan wettiglik ekstra transaksies uitvoer.

Gebruik die gekose biblioteek se proxy-verifikasiekoppelvlak en ondersoek dan die effektiewe skema en omvang. 'n Instelling vir bestemming-voorverifikasie beheer dalk nie die proxy-handdruk nie. 'n Bestaande geauthentiseerde verbinding kan ook verberg of 'n nuwe verbinding 'n uitdaging sou uitvoer.

Vergelyk die volle bewerking: aantal uitruilings, voltooiingstyd, vereiste vervoerbeskerming en die gedrag wanneer die proxy verander. 'n Skooner log is net nuttig as die toepassing steeds by die bedoelde tussenganger authentiseer en stop wanneer daardie reëling nie gevestig kan word nie.