proxy-chain: skilde kontoar og upstreamar for kvar listener

proxy-chain kan køyre éin Server-instans per lyttande port. Fest policyen til den listeneren i autentiserings-callbacken:

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

Applikasjonen leverer kontoverdiane og upstream-URL-ane via den vanlege konfigurasjonen sin. Kvar callback held på si eiga regel, så å godta kontoen på port 8001 godtar ikkje den kontoen på port 8002.

requestAuthentication true returnerer ei Basic-proxy-utfordring. Når autentisering er kravd, blir upstreamProxyUrl ignorert for den førespurnaden. Ein vellukka innkomande konto og upstream-kontoen er ulike identitetar.

Bruk ein støtta URL for kvar upstream, inkludert rett koda innloggingsdetaljar når det er kravd. For ein offentleg HTTP-upstream utan autentisering, vel ein kandidat frå HTTP-proxylista og bygg URL-en utan innloggingsdetaljar. Ein utelaten upstream vel direkte videresending i staden for ein annan automatisk proxy.

Dømet bind loopback for lokale klientar. Bind grensesnittet som er meint med vilje når ei anna maskin må kopla til, med den tilsvarande tilgangspolicyen.

Hald serverane i live for arbeidsmengda til klientane. Eigaren deira bør lukke kvar server via den støtta lukkemetoden ved avslutning; dømet definerer ikkje den fulle livssyklusen til den applikasjonen.