Antaŭa Basic-prokura aŭtentikigo por konata finpunkto
Decidu kiam antaŭa Basic-prokura aŭtentikigo taŭgas por fiksa finpunkto, kaj ne lasu tiun decidon fariĝi akreditila regulo por arbitraj itineroj.
Kliento, kiu unue atendas defion, atendas ke la prokuro demandu. Antaŭa Basic-kliento jam konas la elektitan finpunkton kaj sendas la akreditilon en sia unua aplikebla peto. Forigi tiun interŝanĝon povas utili. Ĝi tamen restas decido pri tio, kien pasvorto iras.
Konu la finpunkton antaŭ la optimumigo
Fiksa privata prokuro kun konata aŭtentikiga politiko estas pli klara kazo ol enkursiga tavolo, kiu povas elekti nekonatan peranton. Ligu la konton al la atendata prokura identeco kaj protokolo. Ne konstruu ĝeneralan callback, kiu respondas al ĉiu defio per unu firmaa pasvorto.
Basic portas base64-prezenton de la konto, ne ĉifritan pruvon. TLS al la prokura aŭskultanto estas aparta konekta elekto disde la HTTPS-sesio de la retejo. La HTTPS-tunelo de la retejo ne protektas retroaktive Basic-akreditilon senditan tra neĉifrita klient-al-prokura konekto. Privata LAN estas loko, ne ĉifrada eco.
Tenu la mekanismon specifa
Antaŭa Basic ne estas universala fuĝovojo por Digest, NTLM aŭ Negotiate. Tiuj mekanismoj havas proprajn interŝanĝpostulojn. Kliento, kiu malkovras subtenatajn skemojn, rajtas plenumi pliajn transakciojn.
Uzu la prokuran aŭtentikigan interfacon de la elektita biblioteko, poste kontrolu la efektivan skemon kaj amplekson. Agordo por celanta antaŭaŭtentikigo eble ne regas la prokuran manpremon. Ekzistanta aŭtentikita konekto ankaŭ povas kaŝi, ĉu nova konekto plenumus defion.
Komparu la tutan operacion: nombro de interŝanĝoj, finiĝa tempo, bezonata transporta protekto kaj konduto kiam la prokuro ŝanĝiĝas. Pli pura protokolo utilas nur se la aplikaĵo ankoraŭ aŭtentikiĝas al la celita peranto kaj haltas kiam tiu aranĝo ne povas esti establita.