Logitech Options+ за прокси

Обычная версия Logitech Options+ отказывается корректно работать за корпоративным прокси: установка проходит успешно, однако проверка обновлений, а также загрузка информации о девайсах не работает, в итоге ни один девайс добавить не получаестя. Решение - использовать оффлайн-установщик, он не требует подключения к интернету для загрузки информации о девайсах: https://prosupport.logi.com/hc/en-us/articles/10991109278871-Logitech-Options-Offline-Installer. 

Запуск Tomcat 8 из Netbeans 8.2 и Netbeans 10.0: ошибка "Не удается найти указанный файл"

Проблема

Установил Netbeans 8.2 вместе с Tomcat 8, пробую запустить Tomcat из Netbeans. В выводе старта томката получаю ошибку:

Using CATALINA_BASE:   "C:\Users\aspirinspb\AppData\Roaming\NetBeans\8.2\apache-tomcat-8.0.27.0_base"
Using CATALINA_HOME:   "C:\tomcat-8.0.27"
Using CATALINA_TMPDIR: "C:\Users\aspirinspb\AppData\Roaming\NetBeans\8.2\apache-tomcat-8.0.27.0_base\temp"
Using JRE_HOME:        "C:\Program Files\Java\jdk1.7.0_80"
Using CLASSPATH:       "C:\tomcat-8.0.27\bin\bootstrap.jar;C:\tomcat-8.0.27\bin\tomcat-juli.jar"
Не удается найти указанный файл

(на самом деле вместо  "Не удается найти указанный файл" были кракозябры, это уже расшифрованная фраза, спасибо https://2cyr.com/decode/?lang=ru).
Та же проблема наблюдается на Netbeans 10.0 с тем же Tomcat 8.

Причина

Причина в настройках прокси-сервиса, установленных в IE. Дело в том, что в Netbeans по-умолчанию установлена настройка "Использовать системные настройки прокси". А в них у меня задано исключение из проксируемых адресов по маске: "*.domain.ru;172.26.*". В итоге Netbeans формирует следующий параметр для старта томката:

-Dhttp.nonProxyHosts=*.domain.ru^|172.26.*^|<local> 

Что и вызывает невнятную ошибку  "Не удается найти указанный файл". Пока просто отключил использование прокси в настройках Netbeans.

Msxml2.XMLHTTP: работа за проксёй в локальном скрипте

Итак, есть некий локальный JScript-скрипт, выполняемый на виндовой машине через cscript. В нем используется XHR-запрос, объект при этом создается следующим образом:

var xmlhttp = new ActiveXObject("Msxml2.XMLHTTP");

При этом соединение с нужным ресурсом выполняется по https. 

Все было в порядке, пока скрипт не был перенесен на другую машину, где при попытке загрузить XML по старому URL-у вдруг стала падать ошибка:

msxml3.dll: Security certificate required to access this resource is invalid

Ладно, предположим, что-то не так с SSL-сертификатом, хотя раньше проблем с ним не было. Переходим на объект Msxml2.ServerXMLHTTP и отключаем валидацию сертификатов:

var xmlhttp = new ActiveXObject("Msxml2.ServerXMLHTTP");
xmlhttp.setOption(2, 13056);

(почему 2 и 13056 - см. https://msdn.microsoft.com/en-us/library/ms763811(v=VS.85).aspx). Проблема с сертификатом пропала, зато теперь получаем:

msxml3.dll: The operation timed out

Идем дальше. меняем объект на Msxml2.ServerXMLHTTP.6.0, поддерживающий установку таймаутов:

var xmlhttp = new ActiveXObject("Msxml2.ServerXMLHTTP.6.0");
xmlhttp.setTimeouts(60000, 60000, 60000, 60000);
xmlhttp.setOption(2, 13056);

Однако, проблема продолжает воспроизводиться, по прошествии минуты падает таймаут, хотя загружаемый ресурс 100% доступен и отвечает за время в пределах 10сек. И тут возникает мысль, что "проблемная" машина сидит за прокси-сервером, пробуем:

var xmlhttp = new ActiveXObject("Msxml2.ServerXMLHTTP.6.0");
xmlhttp.setTimeouts(60000, 60000, 60000, 60000);
xmlhttp.setOption(2, 13056);
xmlhttp.setProxy(2, '<proxyhost>:<proxyport>','');
xmlhttp.open('GET', 'http://myurl', false);
xmlhttp.setProxyCredentials('<proxy_user>', '<proxy_password>');

Вуаля, проблема решена.

IE: отключение прокси-сервера с помощью reg-файла

Задача

Отключить прокси-сервер в IE (а также, например, в Chrome, который использует настройки прокси из IE), т.е. снять галочку "Use a proxy server for your LAN", с помощью скрипта.

Решение

Для начала делаем reg-файл со следующим содержимым:

Windows Registry Editor Version 5.00

[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings]
"ProxyEnable"=dword:00000000 

Затем создаем bat-ник с одной единственной командой:

regedit.exe /s "C:\path\to\reg-file" 

Если нужно снимать галочку по какому-либо событию либо периодически, то идем в планировщик и создаем там задачу с соотв. action'ом:

На вкладке "General" нужно установить "Run with highest privileges".

Ruby: bundle за прокси с авторизацией

Для работы gem за прокси (с авторизацией или без неё) предусмотрен специальный параметр --http-proxy:

gem ... --http-proxy http://user:password@host:port

Для bundle такого параметра нет, но управлять использованием прокси можно через переменную окружения "http_proxy":

export http_proxy=http://user:password@host:port
bundle install ... 

jTrust: OnlineCrlRepository и прокси с авторизацией

Онлайн-репозиторий CRL из библиотеки jTrust реализует загрузку CRL-файлов по указанным URL`ам точек распространения сертификатов (CRL Distribution Points). Поддержка прокси в нем есть, и реализуется она передачей объекта NetworkConfig в конструктор класса:

import be.fedict.trust.NetworkConfig;
import be.fedict.trust.crl.OnlineCrlRepository;
// ...
NetworkConfig nwcfg = new NetworkConfig(proxyHost, proxyPort);
OnlineCrlRepository onlineCrlRepo = new OnlineCrlRepository(nwcfg); 

Но такой вариант работает только с прокси-серверами без авторизации.

В тоже время Apache HttpClient, используемый классом OnlineCrlRepository для загрузки файла CRL, авторизацию на прокси поддерживает (не уверен, что все возможные варианты авторизации реализованы, но по крайней мере BASIC есть): http://hc.apache.org/httpclient-3.x/authentication.html#Proxy_Authentication. Но т.к. внутренние поля и методы OnlineCrlRepository являются закрытыми, наследовать его для добавления нового функционала нет особого смысла, приходится копировать исходники в свой класс, добавляя возможность установки авторизации на прокси. 

Для этого я, во-первых, создал специальный класс ProxyCredentials, унаследовав be.fedict.trust.Credentials, предназначенный для хранения данных http-авторизации. Класс  be.fedict.trust.Credentials содержит метод init(), который применяет авторизационные данные к объекту HttpState. Этот метод я и переопределил таким образом, чтобы он задавал не данные авторизации на конечном сайте, а данные авторизации на прокси, заменив вызов httpState.setCredentials() на httpState.setProxyCredentials():

public class ProxyCredentials extends be.fedict.trust.Credentials
{
  @Override
  public void init(HttpState httpState) {
      for (Credential credential : this.getCredentials()) {
        AuthScope authScope = new AuthScope(credential.getHost(),
            credential.getPort(), credential.getRealm(),
            credential.getScheme());
        UsernamePasswordCredentials usernamePasswordCredentials = new UsernamePasswordCredentials(
            credential.getUsername(), credential.getPassword());
        httpState.setProxyCredentials(authScope, usernamePasswordCredentials);
      }
    }
}

Теперь достаточно в нашем варианте класса OnlineCrlRepository добавить поле для хранения объекта ProxyCredentials, setter-метод для этого поля, а также добавить в метод getCrl() применение этих авторизационных данных к объекту HttpState:

public class AdvancedOnlineCrlRepository implements CrlRepository {

  // ..
  protected ProxyCredentials proxyCredentials;
  /**
   * Sets the credentials for proxy authentication
   * @param proxyCredentials
   */
  public void setProxyCredentials(ProxyCredentials proxyCredentials) {
    this.proxyCredentials = proxyCredentials;
  }

  // ..

protected X509CRL getCrl(URI crlUri) throws IOException,
CertificateException, CRLException, NoSuchProviderException,
NoSuchParserException, StreamParsingException {
HttpClient httpClient = new HttpClient();
if (null != this.networkConfig) {
httpClient.getHostConfiguration().setProxy(
this.networkConfig.getProxyHost(),
this.networkConfig.getProxyPort());
}
if (null != this.credentials) {
HttpState httpState = httpClient.getState();
this.credentials.init(httpState);
}
 
if (null != this.proxyCredentials) {
HttpState httpState = httpClient.getState();
this.proxyCredentials.init(httpState);
}
 
String downloadUrl = crlUri.toURL().toString();
//...
return crl;
}
}

Теперь создание объект репозитория CRL для работы с прокси-сервером с авторизацией выглядит так:

NetworkConfig nwcfg = new NetworkConfig(proxyHost, proxyPort);
ProxyCredentials creds = new ProxyCredentials();
Credential cred = new Credential(proxyHost, proxyPort, proxyLogin, proxyPassword);
creds.addCredential(cred);
AdvancedOnlineCrlRepository onlineCrlRepo = new AdvancedOnlineCrlRepository(nwcfg);
onlineCrlRepo.setProxyCredentials(creds);

Debian / Mint: apt-get за прокси с авторизацией

Чтобы apt заработал за проксей с basic http авторизацией в Debian, нужно прописать в /etc/apt/apt.conf:

Acquire{
http
{
Proxy "http://user:pass@proxy_host:proxy_port";
};
};

В Linux Mint аналогично, но из-за отсутствия apt.conf нужно создать файл в /etc/apt/apt.conf.d/, назвав его, например, "02proxy", и записать приведенный выше конфиг туда.

Настройка прокси с авторизацией в build-файлах ant

Настройка прокси с авторизацией в build-файлах ant осуществляется с помощью задания setproxy:

<setproxy proxyhost="${proxy.host}" proxyport="${proxy.port}"
      proxyuser="${proxy.user}" proxypassword="${proxy.pass}"/>

Конфигурация Apache2 HTTP Server: относительные приоритеты директив Redirect, ProxyPass и RewriteRule

Не знаю, написано ли это где-то в документации по Apache2 (я по крайней мере не нашел), но директива ProxyPass имеет больший приоритет, чем директива Redirect, независимо от порядка их следования в файле конфигурации, т.е. если мы имеем следующую конфигурацию:

Redirect permanent /xxx http://ya.ru
ProxyPass / http://google.com/

, то при обращении по URL`у www.myserver.com/xxx вместо браузерного редиректа на Яндекс мы увидим результат проксирования запроса на URL http://google.com/xxx. Чтобы заставить Apache работать, как мы хотим, нужно исключить путь /xxx из проксирования. В таком случае директива Redirect отработает. Получится конфиг вида:

ProxyPass /xxx !
Redirect permanent /xxx http://ya.ru
ProxyPass / http://google.com/

А вот mod_rewrite отрабатывает раньше, чем ProxyPass, поэтому URL`ы, используемые ProxyPass`ом, нужно исключать из правил mod_rewrite. Т.е. конфигурация https`ного виртуального хоста:

ProxyPass /xxx/ balancer://mybalancer/
RewriteEngine On
RewriteCond %{HTTPS} on
RewriteRule (.*) http://%{HTTP_HOST}%{REQUEST_URI}

при обращении в /xxx приведет к редиректу на этот же URL по http, а не к использованию балансировщика mybalancer, как хотелось бы. Чтобы всё заработало, необходимо:

ProxyPass /xxx/ balancer://mybalancer/
RewriteEngine On
RewriteCond %{HTTPS} on
RewriteCond $0 !/xxx/
RewriteRule (.*) http://%{HTTP_HOST}%{REQUEST_URI}

java.lang.IllegalArgumentException: Invalid Proxy при использовании Proxy.Type.HTTP для создания сокета

Проблема: 

При попытке использовать прокси типа Proxy.Type.HTTP для создания сокета следующим кодом:

Proxy prx = new Proxy(Proxy.Type.HTTP, new InetSocketAddress("webprox", 8888));
Socket socket = new Socket(prx);

 вылетает исключение:

java.lang.IllegalArgumentException: Invalid Proxy

Решение:

Действительно, при создании ява-сокета использовать HTTP-прокси нельзя, что, в общем-то, и логично =), ведь HTTP-прокси умеет работать только с протоколом HTTP, а сокет является более низкоуровневым объектом, не привязанным ни к какому протоколу прикладного уровня. А вот в URL.openConnection HTTP-прокси использовать уже можно, если, конечно, используемый урлом протокол http или https.

Для создания сокета, работающего через прокси, можно использовать только прокси типа Proxy.Type.SOCKS (и, соответственно, Ваш прокси должен поддерживать Socks).