proxy-chain: listener bakoitzeko kontu eta upstream bereiziak

proxy-chainek Server instantzia bat exekuta dezake entzute-portu bakoitzeko. Gorde listener horren politika bere autentifikazio-callbackean:

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

Aplikazioak kontuen balioak eta upstream URLak bere ohiko konfigurazioaren bidez ematen ditu. Callback bakoitzak bere araua mantentzen du, beraz kontua 8001 portuan onartzeak ez du kontu hori 8002 portuan onartzen.

requestAuthentication true balioak Basic proxy erronka bat itzultzen du. Autentifikazioa beharrezkoa denean, upstreamProxyUrl ez da kontuan hartzen eskaera horretarako. Sartzeko kontu arrakastatsua eta upstream kontua identitate desberdinak dira.

Erabili onartutako URL bat upstream bakoitzerako, beharrezkoa denean behar bezala kodetutako kredentzialak barne. Autentifikaziorik gabeko HTTP upstream publiko baterako, hautatu hautagai bat HTTP proxy zerrendatik eta eraiki bere URLa kredentzialik gabe. Utzitako upstream batek zuzeneko birbidalketa hautatzen du beste proxy automatiko baten ordez.

Adibideak loopback lotzen du tokiko bezeroentzat. Lotu nahi den interfazea nahita beste makina batek konektatu behar duenean, dagokion sarbide-politikarekin.

Mantendu zerbitzariak bizirik beren bezeroen lan-kargarako. Jabeak zerbitzari bakoitza itxi beharko luke itzaltzean onartutako itxiera-metodoaren bidez; adibideak ez du aplikazio horren bizitza-ziklo osoa definitzen.