URL პროქსის შესვლა Emacs 31.1-ში: auth-source და CONNECT-ის ზღვრები

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

ქვემოთ მოცემული დეტალები მიჰყვება Emacs 31.1-ს. ისინი ეხება ოპერაციებს, რომლებიც იყენებენ URL ბიბლიოთეკას; Emacs პაკეტის მიერ გაშვებულ გარე ჩამომტვირთავს აქვს თავისი ავთენტიფიკაციის გზა.

დააყენეთ მარშრუტი, შემდეგ მიეცით HTTP-ს შესვლის მოთხოვნის უფლება

ფიქსირებული პროქსის საბოლოო წერტილი შეიძლება აირჩეს დოკუმენტირებული ოფციით:

(setq url-proxy-services
      '(("http" . "proxy.example:8080")
        ("https" . "proxy.example:8080")))

შეცვალეთ ჩასმული ადგილი მოწოდებული საბოლოო წერტილით. გასაღებები აღწერენ დანიშნულების URL სქემებს. HTTPS ჩანაწერის დამატება ირჩევს მარშრუტს HTTPS დანიშნულებებისთვის; ის თავისთავად არ აწვდის სერტიფიკატებს.

ჩვეულებრივი HTTP მოთხოვნის დროს პროქსის შეუძლია უპასუხოს 407 Proxy Authentication Required-ით და Proxy-Authenticate გამოწვევით. URL ბიბლიოთეკა ირჩევს მხარდაჭერილ ავთენტიფიკაციის სქემას და იღებს სერტიფიკატებს პროქსის საბოლოო წერტილისთვის. შემდეგ ის ხელახლა ცდილობს Proxy-Authorization-ით.

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

მოათავსეთ მუდმივი სერტიფიკატები auth-source-ში

თუ auth-source უკვე კითხულობს დაშიფრულ სერტიფიკატების ფაილს, როგორიცაა ~/.authinfo.gpg, ამ მაგალითისთვის Basic ჩანაწერს აქვს შემდეგი ფორმა:

machine proxy.example port http login YOUR_LOGIN password YOUR_PASSWORD

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

Emacs 31.1-ის Basic იმპლემენტაციაში ორი დეტალი მნიშვნელოვანია. ის ეძებს პროქსის ჰოსტის სახელს ციფრული TCP პორტის გარეშე და გადასცემს პროქსის URL-ის სქემას როგორც auth-source-ის პორტის მნიშვნელობას. ამ HTTP პროქსისთვის ეს მნიშვნელობაა http, მიუხედავად იმისა, რომ TCP კავშირი იყენებს პორტს 8080.

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

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

HTTPS-ს აქვს უფრო ადრეული ავთენტიფიკაციის საფეხური

HTTP პროქსის მეშვეობით HTTPS დანიშნულებისთვის Emacs ჯერ აგზავნის CONNECT-ს. ამიტომ ავთენტიფიკაცია შეიძლება დასჭირდეს ვებსაიტთან დაშიფრულ კავშირთან მისვლამდე.

Emacs 31.1-ში CONNECT მოთხოვნის ამწყობი ამოწმებს უკვე ხელმისაწვდომ ავთენტიფიკაციას თავისი ავთენტიფიკაციის მექანიზმის მეშვეობით, მათ შორის ქეშირებულ Basic სერტიფიკატებს. მისი Basic გზა ამ მომენტში არ ითხოვს და არ იღებს ახალ auth-source ჩანაწერს. 200-ისგან განსხვავებული CONNECT პასუხი ასევე არ შედის ზემოთ აღწერილ ჩვეულებრივ HTTP 407 გამოწვევის დამუშავებაში.

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

თუ HTTPS ოპერაცია ჩერდება პროქსიზე, დაადგინეთ მიიღო თუ არა CONNECT-მა 407 და იყენებთ თუ არა ამ გამოშვების ქცევას. დაადასტურეთ ასევე პროქსის მიერ შეთავაზებული ავთენტიფიკაციის სქემა. Basic სერტიფიკატების ჩანაწერი არ არის უნივერსალური ადაპტერი ყველა საწარმოო ავთენტიფიკაციის სისტემისთვის.

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