ارزیابی PAC در Jint: کمک‌تابع‌های گمشده و نتایج مسیر

اگر Jint هنگام ارزیابی PAC نبودِ dnsResolve یا myIpAddress را گزارش کند، بارگذاری JavaScript بیشتر لزوماً راه‌حل نیست. آن کمک‌تابع‌ها به محیطی تعلق دارند که برنامه میزبان فراهم می‌کند.

پیش از فراخوانی FindProxyForURL

مجموعه کمک‌تابع‌های PAC پشتیبانی‌شده و خانواده‌های نشانی را انتخاب کنید، سپس آن‌ها را روی موتور نصب کنید. قراردادهایشان را حفظ کنید: dnsResolve نام میزبان می‌گیرد، myIpAddress هیچ آرگومانی نمی‌گیرد و به سیاست واسط محلی نیاز دارد، و shExpMatch از الگوهای سبک شل استفاده می‌کند. یک بدل که مقدار راحتی برگرداند می‌تواند بی‌صدا مسیر نادرست را انتخاب کند.

با انجام آن مقداردهی اولیه، فراخوانی اصلی در Jint 4.4.0 می‌تواند چنین باشد:

var destination = new Uri(destinationUrl);
engine.Execute(pacSource);
var routeList = engine.Invoke(
    "FindProxyForURL",
    destinationUrl,
    destination.IdnHost
).AsString();

engine همان Jint.Engine پیکربندی‌شده است؛ pacSource برنامه PAC واکشی‌شده است. destination.IdnHost نام میزبان را بدون درگاه یا مسیر می‌دهد. این فراخوانی نه PAC را واکشی می‌کند و نه اتصال پراکسی باز می‌کند.

پس از فراخوانی

نتیجه‌ای مانند PROXY proxy.example:8080; DIRECT را فهرست مرتب نامزدهای مسیر و گزینه پشتیبان بدانید. عبور دادن کل این رشته به‌عنوان نشانی پراکسی معنایش را از بین می‌برد. شکست ارزیابی را از نتیجه صریح DIRECT جدا نگه دارید.

در حین اجرا

محدودیت‌های Jint در مدت، دستور، حافظه و لغو را پیکربندی کنید و تنها توابع میزبان لازم را در معرض دید بگذارید. پاسخ‌های DNS را جداگانه محدود کنید: بررسی‌های اجرای JavaScript یک فراخوانی مسدودکننده دلخواه میزبان را قابل قطع نمی‌کند. دسترسی به یک موتور را سریال کنید یا به کار هم‌زمان نمونه‌های جداگانه با مالکیت مستقل بدهید؛ موتورها برای استفاده هم‌زمان ایمن نیستند.

پیاده‌سازی‌های PAC در مرورگرها می‌توانند در افزونه‌های کمک‌تابع و جزئیات نشانی که آشکار می‌کنند متفاوت باشند، به‌ویژه برای HTTPS. انطباق با یک نتیجه نمونه کمتر از انطباق با رفتار مسیریابی مرورگر را ثابت می‌کند.