Разбор скрипта конфигурации автопрокси в .Net / C#
Чтобы мое приложение (.Net 1.1) могло использовать настроенный системой прокси-сервер (через сценарий proxy.pac), я использовал вызовы взаимодействия для функции WinHTTP WinHttpGetProxyForUrl, передавая URL-адрес proxy.pac, который я получил из реестра.
К сожалению, я попал в сценарий развертывания, где это не работает, поскольку файл proxy.pac развертывается локально на жестком диске пользователя, а URL-адрес - «file: // C: // xxxx»
Как четко указано в документации WinHttpGetProxyForUrl, он работает только со схемами http и https, поэтому он не работает с файлом: //
Я рассматриваю 2 «уродливых» решения проблемы (pac-файл - javascript):
Создание отдельного проекта JScript.NET с одним классом с одним статическим методом Eval (string) и его использование для оценки во время выполнения функции, считанной из файла pac
Создайте во время выполнения сборку JScript.NET и загрузите ее.
Поскольку эти решения действительно уродливы :), кто-нибудь знает лучший подход? Есть ли функция Windows, которую я могу использовать через взаимодействие?
Если нет, что вы, ребята, думаете об этих двух решениях - какое из них вы бы предпочли?
Ответы 4
К сожалению, не могу ответить на вашу проблему (хотя несколько лет назад я играл с jscript.net, и для создания и запуска таким образом потребуется всего несколько строк)
Некоторое время назад я столкнулся с похожей ошибкой proxy.pac с личным файлом work-around-the-office-proxy - в конце концов, я выбрал самый простой вариант и поместил его на собственный сайт IIS, и он был надежным и работает безупречно со всем на моем компьютере.
Иногда лучше сдаться и работать с тем, что есть :)
Я не могу ответить на ваш вопрос напрямую, но, работая с реализацией Mozilla, возникла определенная дискуссия о поддержке URL-адресов файлов. Это были дебаты о контроле сети и удобстве локального пользователя.
Просто подумайте: почему бы не создать микро-веб-сервер, который может обслуживать локальный файл PAC через сокет localhost. Вы должны использовать случайный URI для контента, чтобы его было трудно просматривать неожиданными способами.
Затем вы можете передать URL-адрес, например http: // локальный: 1234 / gfdjklskjgfsdjgklsdfklgfsjkl, в функцию WinHttpGetProxyForUrl и позволить ей получить файл PAC с вашего микросервера.
(взломать ... взломать ... взломать ...)
Сокеты дешевы и просты - HTTP GET одинаково легко анализировать / отвечать. Для меня это звучит почти как решение для новичков. (по сравнению с проведением собственных оценок и т. д.)
Хорошая идея :) Если бы я использовал .Net 2.0, можно было бы использовать HttpListener. Но с 1.1 мне приходится слишком много кодировать. Но +1 за идею.
FWIW: https://web.archive.org/web/20150405115150/http://msdn.microsoft.com/en-us/magazine/cc300743.aspx описывает, как использовать движок JScript.NET, чтобы сделать это безопасно.
https://web.archive.org/web/20090220132508/http://msdn.microsoft.com/en-us/library/aa383910(VS.85).aspx объясняет, как использовать реализацию WinINET.
Обе ссылки кажутся неработающими :( Есть ли способ найти эту конкретную статью по 1. ссылке?
Archive.org - ваш друг.
К сожалению, я не могу этого сделать - мое приложение является конечным пользователем, а это настройка всей компании, и они не собираются ее менять. Возможно, мне удастся убедить их проделать дыру в их брандмауэре, чтобы разрешить непрокси-доступ к нашим серверам, но будет лучше, если у меня будет «встроенное» решение.