დომენით კვალიფიცირებული მომხმარებლის სახელები პროქსის მონაცემებში
განასხვავეთ გაუმჭვირვალე ანგარიშის სახელი ცალკე დომენის ველების მქონე API-ებისგან და მოერიდეთ ანგარიშის იდენტობის შეცვლას მხოლოდ URL-ის სინტაქსის დასაკმაყოფილებლად.
ერთი პასუხი ამბობს, რომ DOMAIN\ უნდა წაიშალოს. მეორე ამბობს, რომ უნდა დაემატოს. ორივე ცვლილება შეიძლება არასწორი იყოს თქვენი პროქსისთვის.
ორი კითხვაა: რომელ იდენტობას ელოდება სერვისი და როგორ წარმოადგენს არჩეული API ამ იდენტობას.
| ინტერფეისი | რა უნდა დადგინდეს |
|---|---|
| ანგარიშის სახელის ერთი ველი | ზუსტი ანგარიშის სინტაქსი, რომელსაც ოპერატორი იღებს |
| მონაცემთა API დომენის ველით | უნდა მიეწოდოს დომენი და მომხმარებლის სახელი ცალ-ცალკე თუ არა |
| მონაცემების კომპონენტები URI-ის შიგნით | როგორ უნდა იყოს დაშიფრული განზრახული მნიშვნელობები ამ კონტეინერისთვის |
მაგალითად, .NET ავლენს NetworkCredential კონსტრუქტორს მომხმარებლის სახელის, პაროლისა და დომენის ცალკე არგუმენტებით. დომენის განურჩევლად ორ ველში ჩასმა არ არის ინტეგრირებული ავთენტიფიკაციის კონფიგურაციის გადატანადი გზა.
Basic ავთენტიფიკაცია სხვა შემთხვევაა: სერვერი მოწოდებულ ანგარიშის ტექსტს საკუთარი პოლიტიკით განმარტავს. ერთსა და იმავე ქსელში ყოფნა არ ამტკიცებს, რომ დომენის პრეფიქსი იგულისხმება. ასევე, დომენით კვალიფიცირებული სახელი ავტომატურად განსხვავებული ავთენტიფიკაციის პროტოკოლი არ არის.
URL-ესკაპირებამ უნდა შეინარჩუნოს განზრახული ანგარიში და არა შეცვალოს იგი. უკუდახრილი საწყისი ენის სტრიქონში, უკუდახრილი ანგარიშის სახელში და მისი პროცენტული კოდირება URI-ის შიგნით ცალკე შრეებია.
მიიღეთ მისაღები იდენტობის ფორმა და სქემა ოპერატორისგან, შემდეგ გამოიყენეთ შესაბამისი მონაცემთა ინტერფეისი. მოკლე სახელს, დომენის სახელსა და ელფოსტის მსგავს სახელს შორის შემთხვევითი მონაცვლეობა სუსტ მტკიცებულებას ქმნის საწყისი 407-ის შესახებ.