proxy-chain можа запускаць адзін экзэмпляр Server на кожны порт праслухоўвання. Захавайце палітыку гэтага слухача ў яго зваротным выкліку аўтэнтыфікацыі:

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

Прыкладанне перадае значэнні ўліковых запісаў і URL-адрасы upstream праз сваю звычайную канфігурацыю. Кожны зваротны выклік захоўвае ўласнае правіла, таму прыняцце ўліковага запісу на порце 8001 не прымае гэты запіс на порце 8002.

requestAuthentication true вяртае запыт проксі Basic. Калі патрабуецца аўтэнтыфікацыя, upstreamProxyUrl для гэтага запыту ігнаруецца. Паспяховы ўваходны ўліковы запіс і ўліковы запіс upstream — розныя асобы.

Выкарыстоўвайце падтрыманы URL для кожнага upstream, уключаючы правільна закадаваныя ўліковыя даныя, калі гэта патрабуецца. Для публічнага HTTP-upstream без аўтэнтыфікацыі выберыце кандыдата з спісу HTTP-проксі і пабудуйце яго URL без уліковых даных. Прапушчаны upstream выбірае прамую перадачу, а не іншы аўтаматычны проксі.

Прыклад прывязвае loopback для лакальных кліентаў. Прывязвайце патрэбны інтэрфейс свядома, калі павінна падключыцца іншая машына, з адпаведнай палітыкай доступу.

Трымайце серверы жывымі для працы іх кліентаў. Уласнік павінен закрываць кожны сервер яго падтрыманым метадам закрыцця пры спыненні; прыклад не вызначае поўны жыццёвы цыкл гэтага прыкладання.

Падобныя артыкулы