Калі Jint паведамляе пра адсутнасць dnsResolve або myIpAddress падчас ацэнкі PAC, загрузка дадатковага JavaScript не абавязкова вырашыць праблему. Гэтыя памочнікі PAC належаць асяроддзю, якое падае праграма-хост.

Перад выклікам FindProxyForURL

Выберыце падтрыманы набор памочнікаў PAC і сямействы адрасоў, затым усталюйце гэтыя памочнікі ў рухавіку. Захоўвайце іх кантракты: dnsResolve прымае імя хоста, myIpAddress не прымае аргументаў і патрабуе палітыкі лакальнага інтэрфейсу, а shExpMatch выкарыстоўвае шаблоны ў стылі shell. Заглушка, якая вяртае зручнае значэнне, можа моўчкі выбраць няправільны маршрут.

Пасля гэтай ініцыялізацыі асноўны выклік у 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, як упарадкаваны спіс кандыдатаў маршрутаў і рэзервовы варыянт. Перадача ўсяго гэтага радка як праксі-URL пазбаўляе яго сэнсу. Адрознівайце збой ацэнкі ад яўнага выніку DIRECT.

Падчас выканання

Наладзьце абмежаванні Jint па працягласці, аператарах, памяці і скасаванні, а таксама адкрыйце толькі патрэбныя функцыі хоста. Абмяжуйце DNS-звароты асобна: праверкі выканання JavaScript не робяць адвольны блакуючы выклік хоста перарываным. Серыялізуйце доступ да рухавіка або давайце паралельнай працы асобныя ўласныя экзэмпляры; рухавікі небяспечныя для адначасовага выкарыстання.

Рэалізацыі PAC у браўзерах могуць адрознівацца пашырэннямі памочнікаў і дэталямі URL, якія яны паказваюць, асабліва для HTTPS. Супадзенне аднаго прыкладу выніку даказвае менш, чым супадзенне паводзін маршрутызацыі браўзера.

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