proxy-chain kin ien Server-eksimplaar per harkport rinne litte. Fêstje it belied fan dat listener yn syn autentikaasje-callback:

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

De applikaasje leveret de akkountwearden en upstream-URL's fia syn gewoane konfiguraasje. Elk callback behâldt syn eigen regel, dus it akseptearjen fan it akkount op port 8001 akseptearret dat akkount net op port 8002.

requestAuthentication true jout in Basic-proxy-útdaging werom. As autentikaasje fereaske is, wurdt upstreamProxyUrl foar dat fersyk negearre. In suksesfol ynkommend akkount en it upstream-akkount binne aparte identiteiten.

Brûk in stipe URL foar elk upstream, ynklusyf korrekt kodearre ynloggegevens as dat fereaske is. Foar in net-autentisearre iepenbier HTTP-upstream, kies in kandidaat út 'e HTTP-proxylist en bou syn URL sûnder ynloggegevens. In weilitten upstream kiest direkte trochstjoering ynstee fan in oare automatyske proxy.

It foarbyld bynt loopback foar lokale klanten. Bynt de bedoelde ynterface bewust as in oare masine ferbine moat, mei it byhearrende tagongsbelied.

Hâld de servers libben foar de wurklêst fan har klanten. Har eigner moat elke server by it ôfsluten slute fia syn stipe slútmetoade; it foarbyld definiearret net de folsleine libbenssyklus fan dy applikaasje.

Relatearre artikelen