Basic- og Digest-proxyautentisering
Vel ein proxyautentiseringsmetode som er støtta av begge sidene, og skil ein Digest-utfordring frå kryptert transport.
Les proxyen sin Proxy-Authenticate utfordring før du tvingar fram Basic eller Digest. Klienten må støtte ein metode tenesta tilbyr; å velje Digest kan ikkje leggje han til på ein proxy som berre støttar Basic.
For eit endepunkt som støttar Digest, kan curl bruke:
curl --proxy http://proxy.example:3128 --proxy-digest --proxy-user alice --connect-timeout 5 --max-time 15 https://example.com/Bruk det verkelege endepunktet og kontoen. Eit brukarnamn utan passord lèt curl spørje etter det. For Basic vel du --proxy-basic; autentisering mot opphavstenaren bruker andre alternativ. Kontroller både utfordringa og støtta i curl-bygget som faktisk køyrer.
| Metode | Utveksling av påloggingsopplysningar | Vern som skal vurderast |
|---|---|---|
| Basic | Eit koda par med brukarnamn og passord. | Koding er ikkje kryptering. |
| Digest | Eit svar avleidd frå utfordringa. | Algoritmar, utfordringsparametrar og klientimplementasjon avgjer vernet; metoden krypterer ikkje innhaldet i førespurnader og svar. |
Begge treng framleis eigna transport frå klienten til proxyen. HTTPS til målet startar for seint til å verne ei tidlegare proxyinnlogging i klartekst.
På tenaren kan Digest-hjelparar krevje realm-spesifikt legitimasjonsmateriale og sitt eige format. Ei Basic NCSA-fil er ikkje automatisk ein Digest-backend. Bruk det dokumenterte formatet til den valde hjelparen, og kontroller deretter manglande opplysningar, feil opplysningar og ei godkjend førespurnad, samstundes som avgrensingar for kjelde og mål blir haldne ved lag.