Basic პროქსის წინასწარი ავთენტიფიკაცია ცნობილი ბოლო წერტილისთვის

კლიენტი, რომელიც ჯერ გამოწვევას ელოდება, ელოდება, სანამ პროქსი იკითხავს. წინასწარი Basic კლიენტმა უკვე იცის არჩეული ბოლო წერტილი და სერტიფიკატს პირველივე შესაბამის მოთხოვნაში აგზავნის. ამ გაცვლის მოცილება შეიძლება სასარგებლო იყოს. მაინც რჩება გადაწყვეტილება იმაზე, სად მიდის პაროლი.

იცანით ბოლო წერტილი ოპტიმიზაციამდე

ფიქსირებული კერძო პროქსი ცნობილი ავთენტიფიკაციის პოლიტიკით უფრო ნათელი შემთხვევაა, ვიდრე მარშრუტიზაციის შრე, რომელმაც შეიძლება უცნობი შუამავალი შეარჩიოს. დაუკავშირეთ ანგარიში მოსალოდნელ პროქსის იდენტობასა და პროტოკოლს. ნუ ააგებთ ზოგად callback-ს, რომელიც ყოველ გამოწვევას ერთი კომპანიის პაროლით პასუხობს.

Basic ატარებს ანგარიშის base64 წარმოდგენას და არა დაშიფრულ მტკიცებას. TLS პროქსის მსმენელამდე საიტის HTTPS სესიისგან ცალკე კავშირის არჩევანია. საიტის HTTPS გვირაბი უკუძალით არ იცავს Basic სერტიფიკატს, რომელიც გაუშიფრავი კლიენტი-პროქსის კავშირით გაიგზავნა. კერძო LAN ადგილია, არა დაშიფვრის თვისება.

შეინარჩუნეთ მექანიზმი კონკრეტული

წინასწარი Basic არ არის უნივერსალური მოკლე გზა Digest-ისთვის, NTLM-ისთვის ან Negotiate-ისთვის. ამ მექანიზმებს საკუთარი გაცვლის მოთხოვნები აქვთ. კლიენტს, რომელიც მხარდაჭერილ სქემებს აღმოაჩენს, შეუძლია ლეგიტიმურად შეასრულოს დამატებითი ტრანზაქციები.

გამოიყენეთ არჩეული ბიბლიოთეკის პროქსი-ავთენტიფიკაციის ინტერფეისი, შემდეგ შეამოწმეთ ფაქტობრივი სქემა და ფარგლები. დანიშნულების წინასწარი ავთენტიფიკაციის პარამეტრმა შეიძლება პროქსის ხელის ჩამორთმევა არ მართოს. არსებულმა ავთენტიფიცირებულმა კავშირმა ასევე შეიძლება დამალოს, შეასრულებდა თუ არა ახალი კავშირი გამოწვევას.

შეადარეთ მთელი ოპერაცია: გაცვლების რაოდენობა, დასრულების დრო, საჭირო ტრანსპორტის დაცვა და ქცევა, როცა პროქსი იცვლება. უფრო სუფთა ჟურნალი მხოლოდ მაშინაა სასარგებლო, თუ აპლიკაცია კვლავ ავთენტიფიცირდება განზრახულ შუამავალთან და ჩერდება, როცა ეს შეთანხმება ვერ დამყარდება.