Basic- och Digest-autentisering för proxy
Välj en proxymetod som stöds av båda sidor och skilj en Digest-utmaning från krypterad transport.
Läs proxyns Proxy-Authenticate utmaning innan du tvingar fram Basic eller Digest. Klienten måste stödja en metod som tjänsten erbjuder; att välja Digest kan inte lägga till den på en proxy som bara stöder Basic.
För en slutpunkt som stöder Digest kan curl använda:
curl --proxy http://proxy.example:3128 --proxy-digest --proxy-user alice --connect-timeout 5 --max-time 15 https://example.com/Använd den riktiga slutpunkten och det riktiga kontot. Ett användarnamn utan lösenord gör att curl kan fråga efter det. För Basic väljer du --proxy-basic; autentisering mot ursprungsservern använder andra alternativ. Kontrollera både utmaningen och stödet i den curl-build som faktiskt körs.
| Metod | Utbyte av autentiseringsuppgifter | Skydd att bedöma |
|---|---|---|
| Basic | Ett kodat par av användarnamn och lösenord. | Kodning är inte kryptering. |
| Digest | Ett svar som härleds från utmaningen. | Algoritmer, utmaningsparametrar och klientimplementation avgör skyddet; metoden krypterar inte innehållet i begäranden och svar. |
Båda kräver fortfarande lämplig transport från klient till proxy. HTTPS till destinationen börjar för sent för att skydda en tidigare proxyinloggning i klartext.
På servern kan Digest-hjälpare kräva realm-specifikt autentiseringsmaterial och ett eget format. En Basic NCSA-fil blir inte automatiskt en Digest-backend. Använd det dokumenterade formatet för den valda hjälparen och kontrollera sedan saknade uppgifter, felaktiga uppgifter och en behörig begäran, samtidigt som begränsningar för källa och destination behålls.