ലോക്കൽ NTLM പ്രോക്സി സഹായികൾ: ക്ലയന്റ് പ്രവേശനവും അപ്സ്ട്രീം ലോഗിനും

നിങ്ങളുടെ ആപ്പ് അതിന്റെ സ്വന്തം കമ്പ്യൂട്ടറിലെ ഒരു പ്രോക്സിയിലേക്ക് ബന്ധിപ്പിക്കുന്നു. പിന്നീട് ആ സഹായി കമ്പനി പ്രോക്സിയിൽ പ്രമാണീകരിക്കുന്നു. കമ്പനിയുടെ പ്രമാണീകരണ കൈമാറ്റം ആപ്പ് തന്നെ ചെയ്യണമെന്നില്ല.

application → local helper → company proxy → destination

CNTLM പോലുള്ള ഒരു സഹായിക്ക് അപ്സ്ട്രീം അക്കൗണ്ടും പ്രോക്സി ക്രമീകരണവുമുണ്ട്. അതിന്റെ ലോക്കൽ ലിസണറിന് വേറിട്ട ലഭ്യതയും പ്രവേശന പരിധിയുമുണ്ട്. മറ്റൊരു എൻഡ്പോയിന്റിലേക്ക് ബ്രൗസറിൽ നൽകുന്ന പാസ്വേഡ് ഇവ രണ്ടും സ്വയമേവ ക്രമീകരിക്കുന്നില്ല.

പരാജയപ്പെട്ട ഘട്ടം കണ്ടെത്തുക

ആദ്യം ആപ്പ് സഹായിയുടെ യഥാർത്ഥ ലിസണറും പ്രോട്ടോക്കോളും തിരഞ്ഞെടുത്തുവെന്ന് ഉറപ്പാക്കുക. ആ ലിസണറിൽ എത്തുന്നതിന് മുമ്പുള്ള പിശക് NTLM പരാജയമല്ല. തുടർന്ന് സഹായി ക്രമീകരിച്ച പേരന്റിൽ എത്തിയോ, പേരന്റ് അതിന്റെ ഐഡന്റിറ്റി സ്വീകരിച്ചോ എന്ന് പരിശോധിക്കുക.

ഈ പാതയിൽ തിരികെ വരുന്ന 407-ന് ആരോപണം ആവശ്യമാണ്. കാണുന്ന സ്റ്റാറ്റസ് നിങ്ങളുടെ ആപ്പ് അയക്കേണ്ട അക്കൗണ്ടിനെ സൂചിപ്പിക്കുന്നു എന്ന് അനുമാനിക്കാതെ, ലോക്കൽ ഇടപാടിനെ സഹായിയുടെ തിരുത്തിയ ഡയഗ്നോസ്റ്റിക്സുമായി ബന്ധിപ്പിക്കുക.

പഴയ ഉദാഹരണങ്ങൾ ചിലപ്പോൾ keep-alive ഹെഡർ ചേർത്ത് വിജയം റിപ്പോർട്ട് ചെയ്യുന്നു. കണക്ഷൻ കേന്ദ്രീകൃത പ്രമാണീകരണത്തിൽ നിലനിൽപ്പ് പ്രധാനമായേക്കാം, എന്നാൽ ആ നിരീക്ഷണം പരാജയപ്പെട്ട ഓരോ സഹായി ക്രമീകരണത്തിനും അതേ ഹെഡർ വേണമെന്ന് തെളിയിക്കുന്നില്ല. എൻഡ്പോയിന്റ് തിരഞ്ഞെടുപ്പ്, പിന്തുണയ്ക്കുന്ന രീതി, അക്കൗണ്ട്, കണക്ഷന്റെ ആയുസ്സ് എന്നിവ വേറിട്ട ഇൻപുട്ടുകളായി തുടരുന്നു.

ലിസണർ ഒരു യഥാർത്ഥ സേവനമാണ്

Loopback ലിസണറെ ചുറ്റുമുള്ള നെറ്റ്വർക്കിൽ നിന്ന് ഒഴിവാക്കുന്നു; ആ കമ്പ്യൂട്ടറിലെ എല്ലാ പ്രോസസുകളെയും ഉപയോക്താക്കളെയും അത് വേർതിരിക്കുന്നില്ല. ഒരു ഗേറ്റ്വേയോ വിശാലമായ ബൈൻഡിംഗോ സഹായിയുടെ അപ്സ്ട്രീം ഐഡന്റിറ്റി ഉപയോഗിക്കാൻ കഴിയുന്ന വിളിക്കുന്നവരുടെ കൂട്ടം മാറ്റുന്നു. ആ മാറ്റം ബോധപൂർവം വരുത്തുക.

ആവശ്യമായ സ്കീം ചെയ്യാൻ ആപ്പിന് കഴിയാത്തപ്പോൾ അംഗീകരിച്ച സഹായി ക്രമീകരണം ഉപയോഗിക്കുക. ഉപയോഗപ്രദമായ ഫലം അറിയപ്പെടുന്ന അക്കൗണ്ട് ഉടമസ്ഥതയുള്ള അറിയപ്പെടുന്ന പാതയാണ്, ഒരു ഡൗൺലോഡ് യാദൃച്ഛികമായി പ്രവർത്തിക്കാൻ ഇടയാക്കുന്ന വിശദീകരിക്കാത്ത അധിക സേവനമല്ല.