HTTP 407 თუ 401: რომელი შესვლა ვერ სრულდება?
განასხვავეთ პროქსისა და საიტის ავთენტიფიკაცია, შეამოწმეთ სწორი სათაურები და ანგარიშის მონაცემები არასწორ მხარეს არ გაუგზავნოთ.
407 პროქსისთან ავთენტიფიკაციას ითხოვს. 401 სამიზნე რესურსისთვის ავთენტიფიკაციას ითხოვს. ერთ მოთხოვნას ორივე შეიძლება შეხვდეს, ამიტომ პაროლის მიწოდებამდე გაარკვიეთ, ვინ ითხოვს მას.
შეადარეთ სტატუსი და ავთენტიფიკაციის მოთხოვნის სათაურები
| პასუხი | ავთენტიფიკაციის მოთხოვნის სათაური | ანგარიშის მონაცემების სათაური | მონაწილე |
|---|---|---|---|
| 407 Proxy Authentication Required | Proxy-Authenticate | Proxy-Authorization | შუამავალი პროქსი |
| 401 Unauthorized | WWW-Authenticate | Authorization | საწყისი რესურსის ავთენტიფიკაციის პროცესი |
სტატუსი მნიშვნელოვანი პირველი მინიშნებაა, მაგრამ მთელი მიმოცვლა შეამოწმეთ. გვერდის ტექსტში 407-ის გამოჩენა ნამდვილ HTTP 407 პასუხს არ უდრის. ასევე, სპეციალურმა შესვლის გვერდმა შეიძლება 200 დააბრუნოს და აპლიკაციის დონეზე ავთენტიფიკაცია მაინც მოითხოვოს.
რატომ შეიძლება HTTPS საიტამდე მისვლამდე 407-ით ჩავარდეს?
როდესაც ჩვეულებრივი HTTP პროქსი HTTPS მოთხოვნას გადასცემს, კლიენტი, როგორც წესი, ჯერ CONNECT გვირაბს ითხოვს. პროქსიმ ამ CONNECT მოთხოვნისთვის შეიძლება ავთენტიფიკაცია მოითხოვოს. თუ ის არ დასრულდა, დანიშნულების TLS სესია გვირაბით ჯერ არ დამყარებულა. საიტის API ტოკენის შეცვლა ამ ეტაპს, სავარაუდოდ, ვერ გამოასწორებს.
დეტალური გამოტანით ნახეთ, სად ჩნდება ავთენტიფიკაციის მოთხოვნა:
curl --noproxy '' --proxy http://127.0.0.1:8080 --connect-timeout 5 --max-time 15 --verbose https://example.com/ადგილობრივი მსმენელი თქვენით შეცვალეთ და ჟურნალის პირველი მოთხოვნა წაიკითხეთ. CONNECT-ის დროს 407 დანიშნულების TLS-მდეა; მოგვიანებით 401 შეიძლება წარმატებულად შექმნილ გვირაბს მოჰყვეს.
პროქსის მონაცემები პროქსის ინტერფეისით მიაწოდეთ
სანდო ადმინისტრატორის მიერ მოცემული საბოლოო წერტილისა და ანგარიშისთვის curl-ს შეუძლია პროქსის ავთენტიფიკაციის სქემის შეთანხმება და მიუთითებელი პაროლის კითხვა:
curl --proxy http://proxy.example:8080 --proxy-anyauth --proxy-user alice https://example.com/მაგალითის საბოლოო წერტილი და მომხმარებელი ნებადართული სერვისის მონაცემებით შეცვალეთ. მხოლოდ მომხმარებლის მითითება პაროლის პირდაპირ ზედა ბრძანებაში ჩაწერას თავიდან აგაცილებთ. მეთოდების მხარდაჭერა curl-ის აგებასა და პროქსიზეა დამოკიდებული; შეთანხმების ჩავარდნისას ნამდვილი მოთხოვნა და აგების შესაძლებლობები შეამოწმეთ.
პროქსის ავთენტიფიკაციის პარამეტრი curl-ის საწყისი სერვერის მომხმარებლის ავთენტიფიკაციისგან განცალკევებულია. პროქსის მოთხოვნაზე პასუხის ნაცვლად საწყისი სერვერის Authorization სათაური არ დაამატოთ. არც პროქსის ანგარიშის სათაურები გადააგზავნოთ ხელით შეუსაბამო მოთხოვნებში და არც მთელი აპლიკაციისთვის განმეორებით გამოსაყენებელ სათაურებში შეინახოთ.
თუ პროქსი მუდმივად 407-ს აბრუნებს
- დაადასტურეთ, რომ სასურველ პროქსის ჰოსტსა და პორტს იყენებთ.
- Basic-ის ვარაუდის ნაცვლად პროქსის გამოცხადებული სქემები შეამოწმეთ.
- შეამოწმეთ ანგარიშის მდგომარეობა და სერვისის მოთხოვნილი მომხმარებლის სახელის ფორმატი.
- თუ მონაცემები URL-შია, სპეციალური სიმბოლოების გადაცემა შეამოწმეთ.
- გაარკვიეთ, მოითხოვს თუ არა ბრაუზერში ინტეგრირებული კორპორაციული ავთენტიფიკაცია გაშვების გარემოს ან პლატფორმის მხარდაჭერას.
- თუ კლიენტის მტკიცებულება საკმარისი არ არის, ადმინისტრატორს სთხოვეთ სენსიტიური მონაცემებისგან გასუფთავებული მოთხოვნის იდენტიფიკატორი ან სერვერის ჟურნალის ჩანაწერი.
403 ან უარყოფილი CONNECT წარმატებული შესვლის შემდეგაც შეიძლება წვდომის პოლიტიკის გადაწყვეტილება იყოს. პაროლის დამატებითი ცდები აკრძალულ დანიშნულებას არ გახსნის.
დანიშნულების HTTPS პროქსის მონაცემების ყველა მიმოცვლას არ იცავს
პროქსის ავთენტიფიკაცია დანიშნულების TLS-მდე შეიძლება მოხდეს. თუ თავად პროქსისთან კავშირი დაუშიფრავია და მეთოდი მასზე განმეორებით გამოსაყენებელ მონაცემებს ამჟღავნებს, HTTPS დანიშნულება წინა მიმოცვლას უკუქცევით ვერ დაიცავს. აირჩიეთ სერვისისთვის შესაფერისი ტრანსპორტი და ავთენტიფიკაცია; პირადი ანგარიშები უცნობ საჯარო პროქსის არ გაუგზავნოთ.
დეტალური ჟურნალები გაზიარებამდე შეამოწმეთ. მაშინაც კი, თუ ხელსაწყო ჩვეულებრივ ანგარიშის ველებს ფარავს, შეიძლება მომხმარებლები, შიდა საბოლოო წერტილების სახელები, cookie-ები ან სხვა საიდენტიფიკაციო მონაცემები დარჩეს.