proxy-chain: eraldi kontod ja upstreamid iga listeneri jaoks
Looge proxy-chain Serveri eksemplare listeneripõhiste Basic-kontode ja upstream-marsruutidega prepareRequestFunctioni kaudu.
proxy-chain suudab käitada ühte Serveri eksemplari iga kuulamisporti kohta. Fikseerige selle listeneri poliitika selle autentimise callback-funktsioonis:
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()));
Rakendus edastab konto väärtused ja upstream-URL-id oma tavapärase konfiguratsiooni kaudu. Iga callback säilitab oma reegli, seega konto aktsepteerimine pordil 8001 ei aktsepteeri seda kontot pordil 8002.
requestAuthentication true tagastab Basic-proxy väljakutse. Kui autentimine on nõutav, ignoreeritakse selle päringu puhul upstreamProxyUrl-i. Edukas sissetulev konto ja upstream-konto on eraldiseisvad identiteedid.
Kasutage iga upstreami jaoks toetatud URL-i, sealhulgas õigesti kodeeritud mandaate, kui see on nõutav. Autentimiseta avaliku HTTP-upstreami jaoks valige kandidaat HTTP-proxy loendist ja koostage selle URL ilma mandaatideta. Puuduv upstream valib otsese edastuse, mitte teise automaatse proxy.
Näide seob loopbacki kohalike klientide jaoks. Siduge kavandatud liides teadlikult, kui teine masin peab ühenduma, vastava juurdepääsupoliitikaga.
Hoidke serverid nende klientide töökoormuse jaoks elus. Nende omanik peaks iga serveri sulgema selle toetatud sulgemismeetodiga väljalülitamisel; näide ei määratle selle rakenduse täielikku elutsüklit.