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 തലക്കെട്ട് വേറിട്ട ഒരു കൈമാറ്റമായി തുടരുന്നു.