proxy-chain: חשבונות ו-upstream נפרדים לכל listener

צרו מופעי Server של proxy-chain עם חשבונות Basic ומסלולי upstream ייחודיים לכל listener באמצעות prepareRequestFunction.

proxy-chain יכול להריץ מופע Server אחד לכל פורט האזנה. תפסו את המדיניות של אותו listener ב-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()));

היישום מספק את ערכי החשבונות ואת כתובות ה-URL של ה-upstream דרך התצורה הרגילה שלו. כל callback שומר על הכלל שלו, ולכן קבלת החשבון בפורט 8001 אינה מקבלת את החשבון הזה בפורט 8002.

requestAuthentication true מחזיר אתגר proxy מסוג Basic. כאשר נדרש אימות, upstreamProxyUrl מתעלמים ממנו עבור אותה בקשה. חשבון נכנס מוצלח וחשבון ה-upstream הם זהויות נפרדות.

השתמשו ב-URL נתמך לכל upstream, כולל פרטי התחברות מקודדים כראוי בעת הצורך. עבור upstream ציבורי של HTTP ללא אימות, בחרו מועמד מרשימת ה-proxy של HTTP ובנו את ה-URL שלו ללא פרטי התחברות. upstream שהושמט בוחר העברה ישירה במקום proxy אוטומטי אחר.

הדוגמה קושרת loopback עבור לקוחות מקומיים. קשרו את הממשק המיועד במכוון כאשר מכונה אחרת צריכה להתחבר, עם מדיניות הגישה המתאימה.

השאירו את השרתים פעילים לעומס העבודה של הלקוחות שלהם. הבעלים שלהם צריך לסגור כל שרת באמצעות שיטת הסגירה הנתמכת שלו בכיבוי; הדוגמה אינה מגדירה את מחזור החיים המלא של אותו יישום.

מאמרים קשורים