Для диагностики проблем в некоторых случаях помогает страница диагностики. Она доступна всем пользователям системы по url /.system/diag.html. Попросите удаленных пользователей воспользоваться возможностями этой страницы.

Описание проблемы:

На клиенте - проходит авторизация, проходит получение данных дерева каталогов и гридов. При этом не проходят запросы на совершение действий и не проходят запросы после задания условий отбора. 

На сервере  - В отладочном мониторе появляются сообщения "Socket became inactive in first line" или "Bad first line".

Причины проблемы:

Проблема связана с особенностями провайдера клиента.  У провайдера установлено ограничение на длину любого http-запроса, либо POST-запроса в 1KB или немногим более.

Обычно проблема проявляется при использовании Microsoft (ISA) Internet Security and Acceleration Server на маршрутизаторе локальной сети.

Для диагностики такой ситуации можно использовать командный сценарий проверки провайдера   (пример) . Сценарий покажет, что отказ происходит именно при отправке запроса, размер которого превышает 1 КВ. Вы можете написать собственный сценарий проверки, лучше соответствующий вашей ситуации, и распространить его своим клиентам.

Запуск файла производится из окружения интерпретатора командной строки Windows (cmd.exe)

Решение проблемы лежит не в области функциональности программного продукта, а в области его эксплуатации, конкретнее - в области организации взаимодействия между web-сервером и клиентскими рабочими местами пользователей. Проблема должна решаться специалистами, отвечающими за сопровождение программного продукта у тех клиентов, у которых имеет место описанное выше ограничение.

Пути решения проблемы:

1. Обратиться к провайдеру с просьбой о снятии ограничения на размер запросов.

2. Использовать нестандартный TCP/IP порт, договорившись с провайдером о его открытии с серверной и клиентской стороны. Данный путь не гарантирует решения проблемы, но может помочь.

В данном случае "провайдером" может выступать как администратор локальной сети организации, так и ISP (интернет-провайдер), в зависимости от того, как организовано подключение конечного пользователя.

3. Использовать протокол https. В этом случае провайдер не сможет анализировать содержимое обмена и, следовательно, не сможет применять ограничения. Для использования протокола https необходимо иметь сертификат, а также внести изменения в настройки web-сервера.

Первые два пути могут способствовать быстрому решению проблемы. При этом стратегически правильным является путь 3 - использование протокола https.

Взаимодействие по протоколу https может быть организовано с использованием сертификатов двух видов:

1) Сертификат, выдаваемый уполномоченными организациями ("настоящий" сертификат).

Инструкция по получению "настоящего" сертификата включена в данное руководство, а также доступна по адресу: http://app.techmill.ru/paruspub/current/documentation/ED01679A80A74E999952269A89D95D36.html

 2) Самостоятельно сгенерированный сертификат.

Инструкция по генерации такого сертификата приведена Здесь. При использовании самостоятельно сгенерированного сертификата браузер пользователя будет выдавать предупреждение о сомнении в его достоверности. О том как избежать отображения такого предупреждения также написано Здесь. Действия по установке настроек web-сервера для работы по протоколу https описаны Здесь.

01@echo off
02IF "%1"=="" GOTO NOHOST
03
04echo Checking connection...
05AppServerFetch download %TEMP%\1.bin from http://%1/ >nul
06IF NOT %ERRORLEVEL%==0 GOTO ERROR
07echo passed.
08
09echo Checking DataMill Application Server....
10AppServerFetch download %TEMP%\1.bin from http://%1/.system/session.xml >nul
11IF NOT %ERRORLEVEL%==0 GOTO ERROR
12echo passed.
13
14echo Checking long GET....
15AppServerFetch download %TEMP%\1.bin from http://%1/.system/session.xml?data=0123456789^
160123456789012345678901234567890123456789012345678901234567890123456789^
170123456789012345678901234567890123456789012345678901234567890123456789^
180123456789012345678901234567890123456789012345678901234567890123456789^
190123456789012345678901234567890123456789012345678901234567890123456789^
200123456789012345678901234567890123456789012345678901234567890123456789^
210123456789012345678901234567890123456789012345678901234567890123456789^
220123456789012345678901234567890123456789012345678901234567890123456789^
230123456789012345678901234567890123456789012345678901234567890123456789^
240123456789012345678901234567890123456789012345678901234567890123456789^
250123456789012345678901234567890123456789012345678901234567890123456789^
260123456789012345678901234567890123456789012345678901234567890123456789^
270123456789012345678901234567890123456789012345678901234567890123456789^
280123456789012345678901234567890123456789012345678901234567890123456789^
290123456789012345678901234567890123456789012345678901234567890123456789^
300123456789012345678901234567890123456789012345678901234567890123456789^
310123456789012345678901234567890123456789012345678901234567890123456789^
320123456789012345678901234567890123456789012345678901234567890123456789^
330123456789012345678901234567890123456789012345678901234567890123456789^
340123456789012345678901234567890123456789012345678901234567890123456789^
350123456789012345678901234567890123456789012345678901234567890123456789^
3601234567890 > nul
37IF NOT %ERRORLEVEL%==0 GOTO ERROR
38echo passed.
39
40echo Checking POST....
41echo 01234567890 > %TEMP%\2.bin
42AppServerFetch download %TEMP%\1.bin from http://%1/.system/session.xml sending %TEMP%\2.bin >nul
43IF NOT %ERRORLEVEL%==0 GOTO ERROR
44echo passed.
45
46
47echo Checking long POST....
48for /L %%i in (1,1,100) DO echo 01234567890 >> %TEMP%\2.bin
49AppServerFetch download %TEMP%\1.bin from http://%1/.system/session.xml sending %TEMP%\2.bin >nul
50IF NOT %ERRORLEVEL%==0 GOTO ERROR
51echo passed.
52
53exit /B 0
54:ERROR
55echo Failed.
56exit /B 1
57:NOHOST
58echo Host not given.
59exit /B 2

Описание проблемы:

На клиенте - ошибка " 403 Forbidden " при попытке входа в систему.

На сервере  - наблюдается неконтролируемый рост числа сессий с одного ip-адреса.

Причины проблемы:

Удаленные клиенты идентифицируются сервером при помощи ip-адреса и "идентификатора сессии", который поддерживается посредством механизма cookies.

Механизм cookies используется следующим образом:

- при первом обращении клиента к серверу, сервер генерирует идентификатор cookie (GUID) и передает его вместе с ответом клиенту; при этом каждая cookie имеет свое время жизни; время жизни задается сервером как момент времени, в который cookie будет уничтожена. Этот момент (в будущем) определяется настройкой "время жизни сессии". В соответствии с требованием стандарта для единства операций со временем (сервер и клиент могут находиться в разных часовых поясах) время указывается по Гринвичу (GMT);

- клиент, получив cookie, прикрепляет ее к каждому своему дальнейшему запросу, до тех пор, пока ее время жизни не истечет; когда время жизни истекает, сервер получает запрос без cookie и выдает ошибку авторизации;

- для сравнения своего текущего времени со временем на Гринвиче и сервер и клиент используют информацию о своем системном времени и своем часовом поясе.

При неверной установке системного времени и/или часового пояса на сервере или на клиенте, возникнет рассинхронизация, и клиент может ошибочно считать время жизни cookie истекшим.

Также очевидно, что решение проблемы лежит не в области функциональности программного продукта, а в области его эксплуатации, конкретнее - решение заключается в настройке web-сервера и рабочих мест удаленных пользователей. Проблема должна решаться специалистами, отвечающими за сопровождение программного продукта у тех клиентов, у которых имеет место описанная проблема.

Пути решения проблемы:

1. Корректно установить время и часовой пояс в системных настройках web-сервера. Для применения новых значений достаточно выполнить перезапуск сервиса DataMill Application Server. 
2. Если, после коррекции системного времени и часового пояса сервера (или если изначально они были установлены правильно), от удаленных пользователей продолжают поступать сообщения об ошибках авторизации, рекомендовать удаленным пользователям корректно выставить системное время и часовой пояс на своей локальной машине. Для применения новых значений пользователю достаточно перезапустить свой браузер.
3. Установить значение параметра "время жизни сессии" в значение, существенно превосходящее один час (например, два часа), поскольку из-за ошибочных установок перехода на летнее время время клиента может расходиться с реальным на час. Это несколько увеличит нагрузку на сервер, однако позволит таким клиентам нормально работать. Следует принимать во внимание, что после отмены перехода на зимнее время часовым поясом для Москвы стал часовой пояс GMT+3.

Описание проблемы:

На клиенте - после успешной авторизации на некоторые запросы возвращается ошибка "403 Forbidden".

На сервере  - несколько запросов в рамках одной сессии приходят с одинакового ip-адреса, далее идут несколько запросов с разных ip-адресов рамках той же сессии. После этого запросы снова идут с первого ip-адреса.

Причины проблемы:

Ошибка происходит в момент смены видимого ip-адреса (запрос приходит на сервер не с того ip-адреса, с которого выполнялась авторизация). Иными словами, имеется проблема нестабильности ip-адреса в рамках одной пользовательской сессии.

Удаленные клиенты идентифицируются сервером при помощи ip-адреса и "идентификатора сессии", который поддерживается посредством механизма cookies. Использование ip-адреса в дополнение к cookies обусловлено следующими факторами:

1. Обеспечение требуемого уровня безопасности.  
   • cookie представляет собой глобально уникальный идентификатор (GUID), генерируемый сервером при первом обращении каждого из клиентов. При этом Microsoft официально утверждает, что вероятность повтора генерируемого GUID крайне мала, но не равна нулю. В связи с этим было принято решение дополнять идентификацию сессии по cookie контролем ip-адреса;
   • не исключена возможность "перехвата" cookie на любом из узлов маршрутизации любого уровня запроса удаленного пользователя; при снятии контроля ip-адреса будет открыта возможность делать запросы с перехваченной cookie с других ip-адресов, не зная логина и пароля пользователя (и получать на эти адреса ответы).
2. Перспектива контроля числа лицензий пользователя, определяемого через число активных подключений, определяемых по ip-адресам.

Пути решения проблемы:

1. Попытаться решить проблему стабильности ip-адреса посредством взаимодействия с администратором сети или провайдером удаленного пользователя. 
2. Внести изменения в систему идентификации сессий, отказавшись от контроля ip-адреса. Этот путь имеет существенные недостатки, связанные со снижением уровня безопасности и теоретической невозможностью контроля web-сервером числа лицензий пользователей.

Вопрос:

- Не отображаются активные сессии в "Настройке сервиса" (используется протокол HTTP)

- Наблюдается очень медленная работа веб-сервиса. Например, на авторизацию и открытие списка отчетов уходит до 10 минут. При этом запросов от BalanceOnline активных в базе нет и ресурсы веб-сервера не загружены.

Ответ:

Причиной описанных проблем является неустойчивый внешний канал связи.

Для решения необходимо в параметрах сетевых настроек сервиса :

1. Включить сжатие трафика;

2. Снять галку "повторно использовать сессии"

3. Если предыдущие шаги не помогли, то увеличить значение параметра "Количество потоков прослушивателя" до 32. Если клиентов ожидается больше 300 (на неусточивом канале), то задать значение в 48 или даже 64 потока. Ставить большее значение не имеет смысла,  в этом случае необходимо расширять внешний канал.

Описание проблемы :

При установленном антивирусе Kaspersky, наблюдается значительное замедление открытия трафаретов в браузере.

Причина проблемы :

Причиной проблемы является установленное в браузер расширение антивируса Kaspersky.

Решение проблемы :

Необходимо отключить это расширение в используемом браузере.

Начиная с 15 версии вышеупомянутого антивируса, отключение этого расширения в браузере не достаточно, т.к. оно снова устанавливается при каждом запуске браузера. Для решения этой проблемы, необходимо отключить автоматическую установку этого расширения в самом антивирусе.

Последовательность действий:

Клиент, используя Windows XP и Microsoft Internet Explorer, любой из доступной для этой ОС версии - 6, 7 или 8, не может соединиться с сервером по протоколу https:

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

1. Браузер пытается использовать шифры RC4 или 3DES, а по умолчанию поддержка этих шифров отключена, по причине их небезопасности. Более того, эти шифры являются единcтвенно возможными в Windows XP для всех версий IE. В следующих ОС Windows, с этими же версиями IE, такой проблемы нет, т.к. в них появилась поддержка шифра AES.
2. Браузер пытается использовать протоколы SSL (вместо TLS), а по умолчанию поддержка этих протоколов отключена, по причине их небезопасности.

Решить проблему правильным и безопасным способом, это посоветовать пользователю воспользоваться другим браузером.

В случаях, когда нужно принять временную меру (плохое и небезопасное решение, крайне не рекомендуется).

1. Как уже упоминалось ранее, шифры RC4 или 3DES являются единcтвенно возможными в Windows XP для всех версий IE. Поэтому без включения поддержки этих шифров на сервере приложений, никакая версия IE работать не будет.
   Для этого, в файле MillAppServer.conf, в элемент /config/object[@class="{91D7A767-7222-4463-BC7F-AD40589E3426}"] добавьте узел <param name="CipherList" value="EECDH+ECDSA+AESGCM EECDH+aRSA+AESGCM EECDH+ECDSA+SHA384 EECDH+ECDSA+SHA256 EECDH+aRSA+SHA384 EECDH+aRSA+SHA256 EECDH+aRSA+RC4 EECDH EDH+aRSA RC4 !aNULL !eNULL !LOW !3DES !MD5 !EXP !PSK !SRP !DSS +RC4 RC4"/>.
2. В случае, когда 1-й пункт выполнен, но проблема остается, то причиной является использование браузером протоколов SSL, вместо TLS.

• Для решения этой проблемы, необходимо посоветовать пользователю настроить свой браузер на использование безопасного протокола TLS (Настройка "Use TLS 1.0" или "Использовать TLS 1.0"):
   
• Либо включить поддержку протоколов SSL на сервере. В файле MillAppServer.conf, в элемент /config/object[@class="{91D7A767-7222-4463-BC7F-AD40589E3426}"] добавьте узел (или замените, если он уже существует)  <param name="MinProtocol" value="0"/>

Рассматривайте эти меры только как временные и переводите удаленных пользователей на более современные системы.

Клиент не может соединиться с сервером по протоколу HTTPS с помощью Internet Explorer в Windows 7, а также других браузеров, не поддерживающих TLS 1.2, вне зависимости от ОС.

По умолчанию, поддержка протоколов TLS 1.0 и TLS 1.1 отключена, по причине их небезопасности. Поэтому в следующих случаях клиент не сможет соединиться с сервисом по протоколу HTTPS:

• любые версии Internet Explorer в случае использования их в Windows 7 или более ранних версиях. В следующих версиях Windows (8.1 и новее) при использовании Internet Explorer 11, такой проблемы нет, т.к. в них появилась поддержка протокола TLS 1.2, который включен по умолчанию. 
• Chrome 28 или более ранние версии, вне зависимости от ОС
• Firefox 26 или более ранние версии, вне зависимости от ОС
• Safari 6 или более ранние версии, вне зависимости от ОС
• Opera 15 или более ранние версии, вне зависимости от ОС

Решить проблему правильным и безопасным способом, это посоветовать пользователю воспользоваться актуальной версией браузера, поддерживающий протокол TLS 1.2 и TLS 1.3.

В случаях, когда нужно принять временную меру (плохое и небезопасное решение, крайне не рекомендуется).

1. Включить поддержку устаревших протоколов TLS 1.0 и TLS 1.1 на сервере приложений.
   Для этого, в файле MillAppServer.conf, в элемент /config/object[@class="{91D7A767-7222-4463-BC7F-AD40589E3426}"] добавьте узел (или замените, если он уже существует):
   

   <param name="MinProtocol" value="2">

2. В случае, когда 1-й пункт выполнен, но проблема остается, то причиной является отключенные в браузере пользователя протоколы TLS 1.0 и TLS 1.1.

• Для решение этой проблемы, пользователю необходимо настроить свой браузер на использование этих протоколов:
  
  •  В настройках Internet Explorer:
    
     
  •  В настройках Firefox:
    - открыть вкладку с адресом about:config
    - найти параметр security.tls.version.enable-deprecated, и если он имеется, то установить его значение равным true.
    - найти параметр security.tls.version.min, и установить его значение равным 1 (TLS 1.0). 

Рассматривайте эти меры только как временные и переводите удаленных пользователей на более современные системы.

В случае работы сервиса за серверным прокси сервером и наблюдением медленной работы удаленного клиента, например есть задержки с получением ответа, в то время как на хосте сервиса видно, что данные отправились быстро, рекомендуется проверить нижеуказанные настройки сервиса:

• Сжимать трафик - выключено, но только в том случае, если на прокси сервере можно настроить сжатие трафика независимо от настройки настоящего сервиса
• Повторно использовать сессии - включено, но только в том случае, если прокси сервер может "эффективно" переиспользовать соединения между ним и сервисом, а не открывать для каждого внешнего клиента отдельное соединение между собой и сервисом
• Отключать алгоритм Nagle для соединений - включено, но только в том случае, если имеется достаточный запас канала между сервисом и прокси сервером

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

Именование настроек для некоторых прокси серверов:

• в IIS - "Response buffer threshold" (Пороговое значение буфера ответов): Application Request Routing Cache > Proxy/Server Proxy Settings
• в NGINX - proxy_buffering, proxy_buffers и proxy_buffer_size

При длительном неиспользовании TCP соединения, роутеры между этими серверами могут начать оптимизировать использование своих ресурсов. Для этого они будут закрывать соединения, которые долго простаивали, обычно порогом является 2 ч. При этом ни сервер приложений, ни сервер СУБД не уведомляются о том, что их соединение оборвалось, и по-прежнему считают его активным.

Результат подобных обрывов соединений является нежелательным ни для сервера приложений, ни для сервера СУБД и будут приводить к многочисленным проблемам, например:

• при необходимости воспользоваться соединением, вызывающая сторона не сразу узнает, что соединение уже неактивно, и будет выжидать таймаут, особенно длительный в ОС Linux (около 15 мин. - см. параметр tcp_retries2) 
• когда сервер приложений поймет, что соединение неактивно, то будет установлено новое соединение, но все данные сброшенного соединения будут потеряны:
  • все активные транзакции текущего соединения, начавшиеся, но еще не завершенные, будут отменены. А это значит, что все выполненные, но еще не подтвержденные действия будут отменены. А также, при последующих запросах клиента в рамках текущей транзакции, он получит ошибку, и будет вынужден выполнять запрос заново.
  • недофетченные селективные запросы сброшены, как на стороне СУБД, так и на стороне сервера приложений. А это значит, что при запросе клиента следующей порции данных из длительных селективных запросов, которые клиент еще не дофетчил до конца, он получит ошибку, и будет вынужден выполнять запрос заново.

Для того чтобы избежать подобных нежелательных обрывов соединений, предлагается ряд административных мер по настройке сервера СУБД для поддержания соединений в активном состоянии.

Проверка и поддержание соединения активным осуществляется следующим образом.
На серверной стороне СУБД, по истечению какого-то времени, клиенту посылаются специальные пакеты определенное количество раз. Как только клиент ответит на эти пакеты проверки соединения, то сервер признает это соединение живым и останавливает этот механизм на определенное время, через которое проверка осуществляется снова. Если клиент не отвечает на проверочные пакеты, то сервер отправляет эти пакеты в течение определенного времени, а затем, если ответ так и не поступил, признает соединение разорванным и закрывает его со своей серверной стороны.

В результате пересылки таких пакетов на простаивающих соединениях будет создаваться трафик и промежуточные роутеры будут считать, что соединение необходимо и еще используется, и не будут обрывать соединения, со своей стороны.

В Oracle, начиная с 12-й версии для этой механики используется настройки TCP соединений, которые хорошо описаны в следующей документации Oracle - Dead connection detection:

• TCP_KEEPIDDLE - время простоя соединения после которого начинаются попытки проверки соединения (отправка спец. пакетов). Значение берется из параметра SQLNET.EXPIRE_TIME, умолчательное значение 0, измеряется в минутах.
• TCP_KEEPCNT - количество попыток проверки соединения (отправка спец. пакетов). Зафиксированное значение (нельзя задать вручную) в Oracle - 10 раз.
• TCP_KEEPINTVL - интервал времени между попытками проверки соединения (отправка спец. пакетов). Зафиксированное значение (нельзя задать вручную) в Oracle - 6 сек.

Таким образом, в Oracle всем этим можно управлять только через настройку SQLNET.EXPIRE_TIME. Умолчательное значение 0, т.е. выключено. Для случаев когда необходимо включить механику поддержки активности соединений, рекомендуемое значение 10 минут.

В Postgres, (в 9.6 эти настройки точно уже присутствуют) есть аналогичные настройки в файле postgres.conf:

• tcp_keepalives_idle - измеряется в секундах. Умолчательное значение 0, в таком случае используется системное значение, которое в Linux и в Windows равняется 2-м часам.
• tcp_keepalives_count - умолчательное значение 0, в таком берется системное значение, которое в Linux равняется 9 раз
• tcp_keepalives_interval - измеряется в секундах. Умолчательное значение 0, в таком берется системное значение, которое в Linux равняется 75 сек.

Таким образом, в Postgres всем этим можно управлять через вышеуказанные настройки в файле конфигурации postgres.conf. Для случаев, когда необходимо включить механику поддержки активности соединений, рекомендуется начать со значений, применяемых Oracle, т.к. они более продуманные и приближенные к жизни, а именно:

• tcp_keepalives_idle - 600 сек, т.е. как и в SQLNET.EXPIRE_TIME, рекомендуется 10 мин
• tcp_keepalives_count - 10 раз
• tcp_keepalives_interval - 6 сек

Важно!

Применять вышеуказанные настройки необходимо на серверной стороне СУБД, для того чтобы сразу охватить все клиентские соединения.