proxy-chain: apartaj kontoj kaj upstream-oj por ĉiu listener

Kreu Server-instancajn de proxy-chain kun Basic-kontoj kaj upstream-vojoj specifaj al ĉiu listener per prepareRequestFunction.

proxy-chain povas funkciigi unu Server-instancan po aŭskulta pordo. Registru la politikon de tiu listener en ĝia aŭtentiga retrovoko:

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()));

La aplikaĵo provizas la kontajn valorojn kaj upstream-URL-ojn per sia normala agordo. Ĉiu retrovoko konservas sian propran regulon, do akcepti la konton ĉe pordo 8001 ne akceptas tiun konton ĉe pordo 8002.

requestAuthentication true redonas Basic-prokuran defion. Kiam aŭtentigo estas postulata, upstreamProxyUrl estas ignorata por tiu peto. Sukcesa envenanta konto kaj la upstream-konto estas apartaj identecoj.

Uzu subtenatan URL por ĉiu upstream, inkluzive de ĝuste koditaj akreditaĵoj kiam necese. Por publika HTTP-upstream sen aŭtentigo, elektu kandidaton el la HTTP-prokura listo kaj konstruu ĝian URL-on sen akreditaĵoj. Forlasita upstream elektas rektan plusendadon anstataŭ alian aŭtomatan prokuron.

La ekzemplo ligas loopback por lokaj klientoj. Ligu la celatan interfacon konscie kiam alia maŝino devas konektiĝi, kun la responda alirpolitiko.

Tenu la servilojn vivaj por la laborŝarĝo de iliaj klientoj. Ilia posedanto devus fermi ĉiun servilon per sia subtenata ferma metodo ĉe malŝalto; la ekzemplo ne difinas la plenan vivociklon de tiu aplikaĵo.

Rilataj artikoloj