Проксі-аўтэнтыфікацыя Basic і Digest
Выберыце метад аўтэнтыфікацыі, які падтрымліваюць абодва бакі, і адрознівайце выклік Digest ад шыфраванага транспарту.
Перш чым прымусова выбіраць Basic або Digest, прачытайце ў Proxy-Authenticate проксі выклік аўтэнтыфікацыі. Кліент мусіць падтрымліваць метад, прапанаваны сэрвісам; выбар Digest не дадасць яго проксі, які падтрымлівае толькі Basic.
Для канцавога пункта з падтрымкай Digest у curl можна выкарыстаць:
curl --proxy http://proxy.example:3128 --proxy-digest --proxy-user alice --connect-timeout 5 --max-time 15 https://example.com/Пакажыце сапраўдны канцавы пункт і ўліковы запіс. Імя карыстальніка без пароля дазваляе curl запытаць яго. Для Basic выберыце --proxy-basic; аўтэнтыфікацыя на зыходным серверы выкарыстоўвае іншыя параметры. Праверце не толькі выклік, але і падтрымку ў зборцы curl, якую сапраўды запускаеце.
| Метад | Абмен уліковымі данымі | Якую абарону ацаніць |
|---|---|---|
| Basic | Закадаваная пара імя карыстальніка і пароля. | Кадаванне не з’яўляецца шыфраваннем. |
| Digest | Адказ, вылічаны на аснове выкліку. | Абарону вызначаюць алгарытмы, параметры выкліку і рэалізацыя кліента; сам метад не шыфруе змесціва запытаў і адказаў. |
Абодвум па-ранейшаму патрэбны прыдатны транспарт ад кліента да проксі. HTTPS да адрасата пачынаецца занадта позна, каб абараніць ранейшы ўваход на проксі адкрытым тэкстам.
На серверы дапаможныя праграмы Digest могуць патрабаваць уліковыя даныя для пэўнага realm і ўласны фармат. Файл NCSA для Basic не становіцца аўтаматычна бэкендам Digest. Выкарыстоўвайце дакументаваны фармат выбранай праграмы, затым праверце адсутныя ўліковыя даныя, няправільныя даныя і дазволены запыт, захоўваючы абмежаванні крыніцы і адрасата.