proxy-chain: ഓരോ listener-നും വെവ്വേറെ അക്കൗണ്ടുകളും upstream-കളും

proxy-chain-ന് ഓരോ ലിസണിംഗ് പോർട്ടിനും ഒരു Server ഇൻസ്റ്റൻസ് പ്രവർത്തിപ്പിക്കാം. ആ listener-ന്റെ നയം അതിന്റെ പ്രാമാണീകരണ callback-ൽ രേഖപ്പെടുത്തുക:

import { Server } from 'proxy-chain';

const listeners = [
  { port: 8001, user: userA, password: passwordA, upstream: upstreamA },
  { port: 8002, user: userB, password: passwordB, upstream: upstreamB },
];
const servers = listeners.map(rule => new Server({
  host: '127.0.0.1',
  port: rule.port,
  prepareRequestFunction: ({ username, password }) => ({
    requestAuthentication:
      username !== rule.user || password !== rule.password,
    upstreamProxyUrl: rule.upstream,
  }),
}));
await Promise.all(servers.map(server => server.listen()));

അപ്ലിക്കേഷൻ അതിന്റെ സാധാരണ കോൺഫിഗറേഷനിലൂടെ അക്കൗണ്ട് മൂല്യങ്ങളും upstream URL-കളും നൽകുന്നു. ഓരോ callback-ഉം സ്വന്തം നിയമം നിലനിർത്തുന്നു, അതിനാൽ പോർട്ട് 8001-ൽ അക്കൗണ്ട് സ്വീകരിക്കുന്നത് പോർട്ട് 8002-ൽ ആ അക്കൗണ്ട് സ്വീകരിക്കുന്നില്ല.

requestAuthentication true ഒരു Basic പ്രോക്സി വെല്ലുവിളി നൽകുന്നു. പ്രാമാണീകരണം ആവശ്യമുള്ളപ്പോൾ ആ അഭ്യർത്ഥനയ്ക്ക് upstreamProxyUrl അവഗണിക്കപ്പെടുന്നു. വിജയകരമായ ഇൻബൗണ്ട് അക്കൗണ്ടും upstream അക്കൗണ്ടും വ്യത്യസ്ത ഐഡന്റിറ്റികളാണ്.

ഓരോ upstream-നും പിന്തുണയ്ക്കുന്ന URL ഉപയോഗിക്കുക, ആവശ്യമെങ്കിൽ ശരിയായി എൻകോഡ് ചെയ്ത ക്രെഡൻഷ്യലുകൾ ഉൾപ്പെടെ. പ്രാമാണീകരണമില്ലാത്ത പൊതു HTTP upstream-നായി HTTP പ്രോക്സി പട്ടികയിൽ നിന്ന് ഒരു സ്ഥാനാർത്ഥിയെ തിരഞ്ഞെടുത്ത് ക്രെഡൻഷ്യലുകളില്ലാതെ അതിന്റെ URL നിർമ്മിക്കുക. ഒഴിവാക്കിയ upstream മറ്റൊരു സ്വയംഭരണ പ്രോക്സിക്ക് പകരം നേരിട്ടുള്ള ഫോർവേഡിംഗ് തിരഞ്ഞെടുക്കുന്നു.

ഉദാഹരണം പ്രാദേശിക ക്ലയന്റുകൾക്കായി loopback ബൈൻഡ് ചെയ്യുന്നു. മറ്റൊരു മെഷീൻ കണക്ട് ചെയ്യേണ്ടിവരുമ്പോൾ ബന്ധപ്പെട്ട ആക്സസ് നയത്തോടെ ഉദ്ദേശിച്ച ഇന്റർഫേസ് ബോധപൂർവ്വം ബൈൻഡ് ചെയ്യുക.

സെർവറുകൾ അവയുടെ ക്ലയന്റുകളുടെ വർക്ക്‌ലോഡിനായി ജീവനോടെ നിലനിർത്തുക. അവയുടെ ഉടമ ഷട്ട്ഡൗൺ സമയത്ത് ഓരോ സെർവറും അതിന്റെ പിന്തുണയ്ക്കുന്ന ക്ലോസ് രീതിയിലൂടെ അടയ്ക്കണം; ഉദാഹരണം ആ അപ്ലിക്കേഷന്റെ പൂർണ്ണ ജീവിതചക്രം നിർവചിക്കുന്നില്ല.