प्रॉक्सीचा पत्ता 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 प्रॉक्सीसाठी, TCP जोडणी पोर्ट 8080 वापरत असली तरी ते मूल्य http आहे.

या शोधात आव्हानाचे realm किंवा अंकीय प्रॉक्सी पोर्ट समाविष्ट नाही. एकाच होस्टनावावर अनेक realm किंवा प्रॉक्सी पोर्टसाठी ती वेगवेगळे Basic पासवर्ड निवडेल अशी अपेक्षा करू नका. Digest वेगळा होस्ट शोध वापरतो, म्हणून वरील उदाहरण विशेषतः Basic साठी आहे.

URL लायब्ररी स्वतःची प्रमाणीकरण कॅशही ठेवते. तिच्या Basic नोंदी प्रॉक्सी एंडपॉइंट वेगळे करतात आणि एंडपॉइंटमध्ये realm किंवा डिरेक्टरी जुळणी वापरतात; ती कॅश auth-source शोधापासून वेगळी आहे. प्रॉम्प्टवर पासवर्ड टाइप केल्याने तुमच्या कायमस्वरूपी क्रेडेन्शियल फाइलमध्ये नवीन नोंद न साठवता सत्र कॅश भरू शकते.

HTTPS ला आधीचे प्रमाणीकरण टप्पा आहे

HTTP प्रॉक्सीद्वारे HTTPS गंतव्यासाठी, Emacs प्रथम CONNECT पाठवते. त्यामुळे वेबसाइटशी एन्क्रिप्टेड जोडणी गाठण्यापूर्वी प्रमाणीकरण आवश्यक असू शकते.

Emacs 31.1 मध्ये, CONNECT विनंती तयार करणारा त्याच्या प्रमाणीकरण यंत्रणेद्वारे आधीच उपलब्ध प्रमाणीकरण तपासतो, कॅश केलेल्या Basic क्रेडेन्शियलसह. त्याचा Basic मार्ग त्या क्षणी नवीन auth-source नोंद मागत नाही किंवा आणत नाही. 200 नसलेला CONNECT प्रतिसादही वर वर्णन केलेल्या सामान्य HTTP 407 आव्हान हाताळणीत जात नाही.

त्यामुळे, सामान्य HTTP Basic आव्हानाला उत्तर देऊ शकणारी auth-source नोंद नवीन सत्राची पहिली HTTPS विनंती यशस्वीरित्या प्रमाणित होईल याची हमी देत नाही. योग्य कॅश क्रेडेन्शियल असलेल्या सत्राची सुरुवातीची स्थिती वेगळी असते. तीच पासवर्ड नोंद वारंवार संपादित केल्याने दोन्ही मार्गांतील हा फरक स्वतःहून दूर होत नाही.

HTTPS क्रिया प्रॉक्सीवर थांबल्यास, CONNECT ला 407 मिळाले का आणि तुम्ही या आवृत्तीचे वर्तन वापरत आहात का हे निश्चित करा. प्रॉक्सीने दिलेली प्रमाणीकरण स्कीमही तपासा. Basic क्रेडेन्शियल नोंद प्रत्येक एंटरप्राइझ प्रमाणीकरण प्रणालीसाठी सार्वत्रिक अडॅप्टर नाही.

कायमस्वरूपी संरचना सार्वजनिक प्रॉक्सी पर्यायात आणि तुम्ही निवडलेल्या क्रेडेन्शियल बॅकएंडमध्ये ठेवा. URL लायब्ररीचा अंतर्गत Basic साठा हे वर्तन समजून घेण्यासाठी उपयुक्त आहे, पण ती खाजगी माहिती रचना हाताने भरल्यास संरचना अंमलबजावणीच्या तपशिलांशी बांधली जाईल.

संबंधित लेख