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 build-ის მხარდაჭერა.
| მეთოდი | საიდენტიფიკაციო მონაცემების გაცვლა | შესაფასებელი დაცვა |
|---|---|---|
| Basic | მომხმარებლის სახელისა და პაროლის კოდირებული წყვილი. | კოდირება დაშიფვრა არ არის. |
| Digest | გამოწვევიდან მიღებული პასუხი. | დაცვას განსაზღვრავს ალგორითმები, გამოწვევის პარამეტრები და კლიენტის იმპლემენტაცია; მეთოდი თავად არ შიფრავს მოთხოვნებისა და პასუხების შინაარსს. |
ორივეს კვლავ სჭირდება შესაბამისი ტრანსპორტი კლიენტიდან პროქსამდე. დანიშნულების HTTPS ძალიან გვიან იწყება, რათა ადრე შესრულებული ღია ტექსტის პროქსის შესვლა დაიცვას.
სერვერზე Digest-ის დამხმარე პროგრამებმა შეიძლება მოითხოვონ კონკრეტული realm-ის რწმუნებათა მასალა და საკუთარი ფორმატი. Basic NCSA ფაილი ავტომატურად Digest backend არ ხდება. გამოიყენეთ არჩეული დამხმარის დოკუმენტირებული ფორმატი, შემდეგ შეამოწმეთ ნაკლული, არასწორი რწმუნებათა მონაცემები და ავტორიზებული მოთხოვნა, წყაროსა და დანიშნულების შეზღუდვების შენარჩუნებით.