proxy-chain: દરેક listener માટે અલગ ખાતાં અને upstreams

proxy-chain દરેક સાંભળતા પોર્ટ માટે એક Server ઉદાહરણ ચલાવી શકે છે. તે listenerની નીતિ તેના પ્રમાણીકરણ કૉલબેકમાં કેદ કરો:

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 પૂરા પાડે છે. દરેક કૉલબેક પોતાનો નિયમ જાળવે છે, તેથી પોર્ટ 8001 પર ખાતું સ્વીકારવું પોર્ટ 8002 પર તે ખાતું સ્વીકારતું નથી.

requestAuthentication true એ Basic પ્રોક્સી પડકાર પરત કરે છે. જ્યારે પ્રમાણીકરણ જરૂરી હોય, ત્યારે તે વિનંતી માટે upstreamProxyUrl અવગણવામાં આવે છે. સફળ આવન ખાતું અને upstream ખાતું અલગ ઓળખ છે.

દરેક upstream માટે સમર્થિત URL વાપરો, જરૂર પડે ત્યારે યોગ્ય રીતે એન્કોડ કરેલ ઓળખપત્રો સહિત. પ્રમાણીકરણ વગરના જાહેર HTTP upstream માટે HTTP પ્રોક્સી સૂચિમાંથી ઉમેદવાર પસંદ કરો અને ઓળખપત્રો વગર તેનું URL બનાવો. છોડી દીધેલ upstream બીજા સ્વયંસંચાલિત પ્રોક્સીને બદલે સીધું ફોરવર્ડિંગ પસંદ કરે છે.

ઉદાહરણ સ્થાનિક ક્લાયન્ટ માટે loopback બાંધે છે. જ્યારે બીજી મશીનને જોડાવું હોય ત્યારે સંબંધિત ઍક્સેસ નીતિ સાથે ઇચ્છિત ઇન્ટરફેસ જાણી જોઈને બાંધો.

સર્વરોને તેમના ક્લાયન્ટના કાર્યભાર માટે જીવંત રાખો. તેમના માલિકે શટડાઉન વખતે દરેક સર્વરને તેની સમર્થિત બંધ પદ્ધતિથી બંધ કરવું જોઈએ; ઉદાહરણ તે એપ્લિકેશનનું સંપૂર્ણ જીવનચક્ર વ્યાખ્યાયિત કરતું નથી.