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 હેડર અલગ વિનિમય જ રહે છે.