proxy-chain: हर listener के लिए अलग खाते और upstream

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 बाइंड करता है। जब किसी दूसरी मशीन को जुड़ना हो, तो संबंधित एक्सेस नीति के साथ इच्छित इंटरफ़ेस जानबूझकर बाइंड करें।

सर्वर को उनके क्लाइंट के कार्यभार के लिए जीवित रखें। उनके मालिक को शटडाउन पर हर सर्वर को उसकी समर्थित बंद करने की विधि से बंद करना चाहिए; उदाहरण उस एप्लिकेशन का पूरा जीवनचक्र परिभाषित नहीं करता।