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 हेडर एक अलग आदान-प्रदान ही रहता है।