Apache ProxyRemote क्रेडेन्शियल्स विरुद्ध proxy-chain-auth

क्लायंट एका खात्याने Apache फॉरवर्ड प्रॉक्सीवर प्रमाणित होऊ शकतो, तर Apache दुसऱ्या खात्याने पॅरेंट प्रॉक्सीवर प्रमाणित होतो:

client ── client account ── Apache ── parent account ── parent proxy

httpd 2.4.59 किंवा नंतरच्या आवृत्तीवर स्थिर पॅरेंट खात्यासाठी ProxyRemote तिसरा आर्ग्युमेंट स्वीकारतो:

ProxyRemote "*" "http://parent.example:3128" "parent-user:replace_with_private_password"

हे विद्यमान प्रवेश-नियंत्रित फॉरवर्ड-प्रॉक्सी कॉन्फिगरेशनला पूरक आहे, उदाहरणार्थ असे खाजगी श्रोता जे क्लायंट IP आणि प्रॉक्सी लॉगिन दोन्ही आवश्यक मानते. खाते निवडलेल्या पॅरेंटचे आहे. ते असलेल्या कॉन्फिगरेशनचे संरक्षण करा आणि तैनातीसाठी आवश्यक जुळणीची व्याप्ती निवडा.

Apache ही Basic क्रेडेन्शियल्स आगाऊ पाठवतो, आधी आव्हानाची वाट न पाहता. त्यामुळे पॅरेंट कनेक्शनचे वाहतूक आणि खाते धोरण महत्त्वाचे ठरते; साइटचे नंतरचे HTTPS सत्र स्वतः पॅरेंटकडे जाणारे स्पष्ट मजकुराचे HTTP झेप संरक्षित करत नाही.

तेच येणारे खाते केव्हा पुढे चालू ठेवावे

Apache सामान्यतः स्वतःला पाठवलेले प्रॉक्सी प्रमाणीकरण वापरतो. proxy-chain-auth पर्यावरण सेटिंग त्याऐवजी क्लायंटची प्रॉक्सी क्रेडेन्शियल्स पुढील प्रॉक्सीकडे पाठवण्यास परवानगी देते:

SetEnv proxy-chain-auth On

हे केवळ हेतुपूर्वक सामायिक प्रमाणीकरण साखळीसाठी योग्य आहे. ते येणारी खाते सामग्री पुढे पाठवते; ते वेगळे पॅरेंट वापरकर्तानाव आणि पासवर्ड तयार करत नाही.

ProxyRemote च्या स्पष्ट क्रेडेन्शियल आर्ग्युमेंटसह proxy-chain-auth चा कोणताही परिणाम होत नाही. कोणता पासवर्ड चालेल या आशेने दोन्ही सेटिंग्ज थरावण्याऐवजी क्रेडेन्शियलचा स्रोत जाणीवपूर्वक निवडा.

हे यंत्रणा प्रॉक्सी झेपींचे प्रमाणीकरण करतात. लक्ष्य साइटचा Authorization हेडर स्वतंत्र देवाणघेवाणच राहतो.