OSX El Capitan и http_proxy с определенным путем к proxypac

322
Papi Antoniadis

Стандартная корпоративная среда, заставляющая клиентов получать через прокси-сервер через proxypac. В конфигурации OSX в следующем формате:

http://www.proxy.server.name:8080/proxy_pac_path_to_package.pac 

Попытка подключения через CLI, для доморощенной установки, и использование (пока) следующих параметров:

export http_proxy=http://www.proxy.server.name:8080/proxy_pac_path_to_package.pac  export http_proxy=http://www.proxy.server.name:8080  export http_proxy=http://myusername:mypasswd@www.proxy.server.name:8080/proxy_pac_path_to_package.pac  export http_proxy=http://myusername:mypasswd@www.proxy.server.name:8080 

со специальными символами mypasswd, отображаемыми в их шестнадцатеричный код, и с именем пользователя, используя либо «простую» форму, либо весь путь AD, либо электронную почту и т. д.

Ничто из перечисленного не сработало. Есть идеи о том, чего мне не хватает, из собственного опыта через неочевидные вещи?

0
Я голосую, чтобы закрыть этот вопрос как не по теме, потому что он больше не может быть воспроизведен. DavidPostill 8 лет назад 0

2 ответа на вопрос

0
Trey

Поскольку у меня нет доступа к вашей корпоративной среде, я не могу сделать окончательный диагноз, но первое, что я хотел бы попробовать вывозит https_proxyи all_proxyс тем же значением (заметим, что https_proxyне может иметь https:URL, он имеет все, http_proxyесть). Выбранные вами значения были правильными (хотя я видел очень странные кодировки имени пользователя / пароля, поэтому не стал бы это списывать со счетов). Я хотел бы убедиться, что Safari работает через прокси, и если вам нужно войти в прокси через Safari, вы сделаете это. Если Safari не работает через прокси-сервер, практически нет шансов, что это сделает Homebrew.

Во-вторых, попробуйте (хотя это voodoo и может быть просто кеширование груза), вы можете попробовать установить его вместо http:схемы в socks5:схему, в противном случае остальная часть URL останется прежней. Я видел эту работу, потому что некоторые прокси больше ориентированы на клиентов Windows и все еще содержат старый код, и из-за плохой записи о совместимости между TCP-стеками версий Windows, SOCKS был более надежным.

Спасибо за быстрый ответ. Вот что «сбивает меня с толку»: - все примеры, которые я до сих пор видел, заканчиваются на конфигурации FQDN: PORT. По некоторым причинам мой прокси-конфиг, выдвинутый с предприятия, имеет пакет ПОСЛЕ порта ... и да - Safari и Chrome работают отлично. Я попробую другие ваши предложения - https имеет смысл, следующий Papi Antoniadis 8 лет назад 0
Pardon if I'm misunderstanding, but the path to the PAC _has_ to go after the FQDN:PORT, because the format of a URL must be `schema://username@host:port/path/name` (with some of those items being optional). If the PAC came before the port, it wouldn't be a port anymore, but an addition to the path name. Trey 8 лет назад 0
0
Papi Antoniadis

Невероятно !!! С моей стороны это была огромная работа: два окна iTerm были открыты одновременно - я выполнял экспорт http_proxy в одном из интерфейса командной строки и тестировал подключение в другом (который, конечно же, не выполнял другой сеанс оболочки, не осознавая этого) из экспортированных переменных в той, в которую я вносил изменения) ... не могу поверить, насколько это глупо. Извините за весь шум ... и благодаря @Trey, что я не был идиотом :-)