Basic kaj Digest-prokurila aŭtentigo
Elektu prokurilan aŭtentigan metodon subtenatan de ambaŭ flankoj, kaj distingu Digest-defion disde ĉifrita transporto.
Legu la de la prokurilo en Proxy-Authenticate defion antaŭ ol devigi Basic aŭ Digest. La kliento devas subteni metodon proponatan de la servo; elekti Digest ne povas aldoni ĝin al prokurilo kiu subtenas nur Basic.
Por finpunkto kiu subtenas Digest, curl povas uzi:
curl --proxy http://proxy.example:3128 --proxy-digest --proxy-user alice --connect-timeout 5 --max-time 15 https://example.com/Uzu la veran finpunkton kaj konton. Uzantnomo sen pasvorto permesas al curl peti ĝin. Por Basic elektu --proxy-basic; aŭtentigo de la origina servilo uzas aliajn opciojn. Kontrolu kaj la defion kaj la subtenon en la efektive rulata curl-konstruaĵo.
| Metodo | Interŝanĝo de legitimiloj | Taksenda protekto |
|---|---|---|
| Basic | Kodita paro de uzantnomo kaj pasvorto. | Kodado ne estas ĉifrado. |
| Digest | Respondo derivita de la defio. | Algoritmoj, defiaj parametroj kaj klienta efektivigo determinas la protekton; la metodo mem ne ĉifras la enhavon de petoj kaj respondoj. |
Ambaŭ ankoraŭ bezonas taŭgan transporton inter kliento kaj prokurilo. HTTPS al la celo komenciĝas tro malfrue por protekti pli fruan ensaluton al la prokurilo en klara teksto.
Ĉe la servilo, Digest-helpiloj povas postuli realm-specifan legitimilmaterialon kaj propran formaton. Basic-NCSA-dosiero ne aŭtomate fariĝas Digest-backend. Uzu la dokumentitan formaton de la elektita helpilo, poste kontrolu mankantajn legitimilojn, malĝustajn legitimilojn kaj rajtigitan peton, konservante la limigojn de fonto kaj celo.