Глава 4. Запуск компонентов системы

При установке «1С:Предприятия» в меню программ оконного менеджера будут созданы следующие ссылки на приложения:

1С:Предприятие A.B.C.D
1С:Предприятие A.B.C.D - Тонкий клиент
1С:Предприятие A.B.C.D - Толстый клиент

В вышеприведенном списке:

При установке «1С:Предприятия» в меню Программы будет создана следующая структура:

1С Предприятие 8 (папка)
    1C:Предприятие
    A.B.C.D (папка)
   1С:Предприятие
   1С:Предприятие - Тонкий клиент
   1С:Предприятие - Толстый клиент
   Удалить 1С:Предприятие

В вышеприведенном списке:

В данной таблице:

● Указание имени какой-либо программы без указания версии означает, что будет использовать программа или файл из той версии, которая была установлена последней в хронологическом порядке.

При установке «1С:Предприятия» в меню Пуск ‑ Программы будет создана следующая структура (приводится для ОС Windows 10):

1С Предприятие
1С Предприятие 8 (папка)
    1C Предприятие (A.B.C.D)
    Тонкий клиент (A.B.C.D)
    Толстый клиент (A.B.C.D)
    Kонфигуратор (A.B.C.D)
    ReadMe - Дополнительная информация
    Регистрация утилиты администрирования серверов (A.B.C.D)
    Администрирование серверов 1С Предприятия
    Запуск сервера (A.B.C.D)
    Установка драйвера защиты
    Удаление драйвера защиты

В вышеприведенном списке:

В данной таблице:

● Указание имени какой-либо программы без указания версии означает, что будет использовать программа или файл из той версии, которая была установлена последней в хронологическом порядке.

● Указание рядом с именем программы конструкции вида (A.B.C.D) означает, что в меню будет столько строк, сколько версий установлено, при этом A.B.C.D означает полный номер установленной версии. Например, если установлено две версии: 8.3.12.100 и 8.3.12 150, то в меню будет две строки Тонкий клиент (8.3.12.100) и Тонкий клиент (8.3.12.150).

● Если установлена 64-разрядная версия системы «1С:Предприятие», то в названии папки и записей в этой папке будет присутствовать строка x86-64.

● Если сервер «1С:Предприятие» установлен в режиме «для пользователя», то он не может работать в режиме сервиса ОС Windows.

Система «1С:Предприятие» может работать в одном из следующих режимов:

Запустить «1С:Предприятие» в каком-либо режиме запуска можно несколькими способами:

● С помощью программы запуска (1cestart) ‑ рекомендованный способ.

● С помощью интерактивной программы запуска (1cv8s).

● С помощью исполняемого файла толстого (1cv8) или тонкого (1cv8c) клиента конкретной версии системы.

● С помощью веб-браузера (только веб-клиент).

Для запуска системы используются конфигурационные файлы:

● Локальный конфигурационный файл ‑ 1cestart.cfg.

● Локальный конфигурационный файл для всех пользователей ‑ 1cestart.cfg.

● Общий конфигурационный файл ‑ 1cescmn.cfg (кроме ОС Linux).

Далее будут подробно описаны способы запуска.

Смотри также:

● 1cestart.cfg (см. здесь);

● 1cescmn.cfg (см. здесь).

Описание расположения файла 1cestart см. здесь.

Программа запуска позволяет запускать все виды клиентских приложений (толстый клиент, тонкий клиент, веб-клиент) и конфигуратор.

Программа запуска может быть запущена либо без параметров, либо с указанием ссылки на конкретную информационную базу.

Если на клиентском компьютере установлена ОС Windows, то:

● Программа запуска также может быть расположена на сетевом ресурсе (для ее работы не требуются дополнительные программные компоненты) и позволяет выполнять как начальную установку системы на компьютер, так и установку новых версий системы программ «1С:Предприятие». Если программа запуска находит общий конфигурационный файл в каталоге, откуда она запущена, то ссылка на этот файл записывается в параметр CommonCfgLocation локального конфигурационного файла.

● При установке системы с помощью программы запуска возможно появление предложения о перезагрузке операционной системы.

Если программа запуска запускается без указания параметров, то используется следующий алгоритм запуска:

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

● Происходит попытка обнаружения локального конфигурационного файла 1cestart.cfg. Поиск выполняется как в каталогах расположения конфигурационных файлов, используемых в режиме установки «для компьютера», так и в каталогах, используемых в режиме установки «для пользователя». В случае успеха происходит считывание параметров из этого файла.

● Происходит поиск установленных версий платформы в соответствии с данными, полученными из параметров InstalledLocation конфигурационных файлов. Если данный параметр не указан в конфигурационных файлах, запуск прекращается с выдачей сообщения об ошибке.

● Определяется максимальный номер установленной версии «1С:Предприятия».

● Определяется максимальный номер версии, доступной к установке, в каталогах, полученных из параметров DistributiveLocation конфигурационных файлов.

● Если существует версия с большим номером, доступная для установки, происходит автоматическая установка новой версии с параметрами, полученными из параметров InstallComponents конфигурационных файлов. Если этот параметр не указан, то выполняется установка тонкого клиента, толстого клиента и компонентов доступа к серверам «1С:Предприятия».

Выбор режима установки зависит от прав текущего пользователя (подробнее см. стр. 72).

● Выполняется запуск интерактивной программы запуска из каталога версии с максимальным номером (существующей или установленной на предыдущем шаге). Запуск выполняется с указанием параметра /AppAutoCheckVersion.

Если программа запуска запускается с указанием имени информационной базы (параметр /IBName), то используется следующий алгоритм запуска:

● Выполняется считывание параметров из локальных (1cestart.cfg, см. здесь) и общего (1cescmn.cfg, см. здесь) конфигурационных файлов.

● Формируется общий список информационных баз из локального списка баз (файл ibases.v8i, см. здесь) и параметров CommonInfoBases конфигурационных файлов.

● Если указанное имя информационной базы не найдено в получившемся списке, запуск прекращается с выдачей сообщения об ошибке.

● Если обнаружена информационная база с указанным именем, то происходит определение параметров запуска из свойств информационной базы и запускается соответствующий клиент с заданными параметрами. Из свойств информационной базы определяются следующие параметры:

● вид клиента;

● номер версии, требуемый для работы;

● разрядность используемого клиентского приложения;

● прочие параметры, хранящиеся в свойствах информационной базы.

● Запуск выполняется с указанием параметра /AppAutoCheckVersion.

Описание расположения файла 1cv8s см. здесь.

Программа запуска позволяет запускать все виды клиентских приложений (толстый клиент, тонкий клиент, веб-клиент), конфигуратор и 1C:Enterprise Development Tools.

Рис. 21. Интерактивная программа запуска

Кнопка 1С:Предприятие запускает клиентское приложение для текущей информационной базы. Кнопка Конфигуратор позволяет зайти в информационную базу конфигуратором, если способ доступа к информационной базе это позволяет. Если информационная база опубликована через веб-сервер, то войти в нее конфигуратором будет невозможно и кнопка будет в недоступном состоянии. С помощью кнопки 1C:EDT предоставляется возможность запустить для текущей информационной базы в списке систему 1C:Enterprise Development Tools. Доступность кнопки регулируется в настройках окна запуска (подробнее см. здесь). Если на текущем компьютере 1C:Enterprise Development Tools не установлены, то будет предложено выполнить установку этого инструмента. Запуск системы 1C:Enterprise Development Tools возможен только интерактивно, из формы интерактивной программы запуска.

Интерактивная программа запуска использует в своей работе некоторые компоненты системы «1С:Предприятие», поэтому последующий запуск клиентского приложения версии, равной версии интерактивной программы запуска, происходит быстрее, чем отдельный запуск исполняемого файла конкретного клиента. Интерактивная программа запуска может быть запущена как интерактивно, так и посредством программы запуска (см. здесь).

При первом запуске интерактивная программа запуска формирует единый список информационных баз, который хранится в файле ibases.v8i (см. здесь). В этот список попадают информационные базы от всех версий «1С:Предприятия». Перенос списка информационных баз версий 8.0 и 8.1 в данный список сопровождается вопросом. Дальнейшая актуализация списка баз не предусмотрена. В процессе первого запуска также выполняется определение расположения каталогов шаблонов конфигураций предыдущих версий и сохранение обнаруженных путей в параметре ConfigurationTemplatesLocation файла 1cestart.cfg (см. здесь). Используемый файл 1cestart.cfg зависит от того, откуда была запущена интерактивная программа запуска.

Интерактивная программа запуска может быть запущена либо без параметров, либо с указанием ссылки на конкретную информационную базу.

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

После того как выбрана конкретная информационная база, интерактивная программа запуска использует следующий алгоритм:

● Если интерактивная программа запуска запущена программой запуска или в интерактивном режиме (с указанием параметра /AppAutoCheckVersion+ или вовсе без указания этого параметра):

● Происходит определение нужной версии для запуска информационной базы и выполняется поиск исполняемых файлов нужной версии (см. здесь).

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

● Затем определяется запускаемый клиент и другие параметры запуска, и происходит попытка запуска необходимого клиента с нужными параметрами из каталога версии (включая параметр /AppAutoCheckVersion).

● Если в каталоге версии не обнаружен нужный клиент, запуск прекращается с выдачей сообщения об ошибке.

● Если интерактивная программа запуска запущена из каталога конкретной версии с указанием параметра /AppAutoCheckVersion-, то:

● Для запуска используются исполняемые файлы только той версии, из каталога которой запущена интерактивная программа запуска.

● Если у запускаемой информационной базы задан автоматический выбор типа клиента, то выполняется запуск тонкого клиента с передачей ему параметра /AppAutoCheckMode (см. здесь).

Запуск интерактивной программы запуска с параметром, указывающим на конкретную информационную базу (параметр /IBName), не отличается от запуска программы запуска (см. здесь).

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

● Информационная база расположена на локальном компьютере или на компьютере в локальной сети.

Используется тонким и толстым клиентами в файловом варианте.

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

● загрузка необходимых для работы системы серверных компонентов;

● загрузка прикладной конфигурации;

● другие действия, необходимые для организации нормальной работы системы с информационной базой.

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

● Информационная база расположена на сервере «1С:Предприятия».

Используется тонким и толстым клиентами в клиент-серверном варианте.

● Информационная база расположена на веб-сервере.

Используется тонким клиентом и веб-клиентом в файловом или клиент-серверном варианте.

Для подключения через веб-сервер необходимо установить и настроить соответствующим образом веб-сервер. Описание настроек различных веб-серверов см. здесь.

В качестве строки соединения с информационной базой при подключении через веб-сервер нужно указать URL, например, следующего вида http://MyServer/DemoBase.

Следующий этап запуска системы «1С:Предприятие» ‑ выбор информационной базы. Для этого служит выдаваемое на экран окно Запуск 1С:Предприятия.

Рис. 22. Запуск «1С:Предприятия»

В списке Информационные базы содержится список информационных баз. Каждая строка списка связана с каким-либо каталогом, в котором находятся файлы информационной базы системы «1С:Предприятие» (для файлового варианта), или сервером и информационной базой на сервере (для клиент-серверного варианта).

В этом списке должна быть выбрана одна из информационных баз. Для выбора необходимо щелкнуть левой кнопкой мыши на названии нужной информационной базы.

Кнопки Изменить, Добавить и Удалить служат для управления списком информационных баз системы «1С:Предприятие» (можно использовать горячие клавиши F2, Ins и Del). Назначение этих кнопок см. здесь.

Размеры окна можно изменить. Положение окна на экране и его размер запоминаются до следующего сеанса.

После того как установлены все необходимые параметры запуска системы «1С:Предприятие», необходимо нажать кнопку 1С:Предприятие для запуска в режиме 1С:Предприятие или Конфигуратор для запуска в режиме Конфигуратор. Нажатие кнопки Выход позволяет отказаться от запуска.

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

Кроме выбора базы из списка информационных баз (см. здесь), имеется возможность запуска с помощью файла .v8i и путем указания параметров открываемой информационной базы в командной строке запуска клиентского приложения (см. здесь). При этом база может быть не зарегистрирована в списке информационных баз. При доступе к такой базе (не зарегистрированной в списке информационных баз на компьютере, с которого выполняется доступ) необходимо помнить, что для такой информационной базы не будет выполняться кеширование данных конфигурации и, как следствие, многие операции будут выполняться существенно медленнее. При обнаружении такой проблемы следует добавить «проблемную» базу в список информационных баз.

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

Конкретный клиент (тонкий или толстый) может быть запущен двумя способами:

● Выбором соответствующего пункта меню (зависит от используемой клиентской операционной системы). Вид клиентского приложения будет определять наличие слов «тонкий клиент» или «толстый клиент» в названии пункта меню.

● Запуском исполняемого файла необходимого клиента (зависит от используемой клиентской операционной системы):

● Для запуска тонкого клиента конкретной версии необходимо запустить файл 1cv8c, описание расположения которого см. здесь.

● Для запуска толстого клиента конкретной версии необходимо запустить файл 1cv8, описание расположения которого см. здесь.

● При запуске файлового варианта информационной базы вначале будет предпринята попытка установки новой версии клиентского приложения (параметр DistributiveLocation конфигурационных файлов) и только потом будет предпринята попытка открыть информационную базу с помощью самой новой версии, установленной на данном компьютере. Отключить установку новой версии можно с помощью параметра командной строки запуска клиентского приложения /AppAutoCheckVersion-. Также установкой новой версии можно управлять с помощью флажка Устанавливать автоматически новую версию диалога настройки окна запуска (см. здесь) и параметра командной строки запуска клиентского приложения /AppAutoInstallLastVersion (см. здесь).

Если соответствующий клиент запущен без параметра /AppAutoCheckMode, то будет предпринята попытка выполнить запуск выбранной информационной базы выбранным клиентом конкретной версии без подбора вида клиентского приложения.

Выбор разрядности клиентского приложения будет использоваться только в том случае, если на компьютере установлена 64-разрядная ОС Windows. При использовании ОС Linux используется приложение, разрядность которого совпадает с разрядностью операционной системы. При использовании ОС macOS доступна только 64-разрядная версия используемых приложений.

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

Для управления разрядностью запускаемого клиентского приложения предназначены (в порядке убывания приоритета использования):

1. ключ командной строки запуска /AppArch;

2. свойство информационной базы;

3. свойство интерактивной программы запуска.

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

1. 32 (x86) ‑ в этом случае всегда будет использоваться 32-разрядная версия клиентского приложения. 64-разрядные версии клиентского приложения будут игнорироваться, даже если среди них есть более свежие версии.

2. 64 (x86-64) ‑ в этом случае всегда будут использоваться 64-разрядная версия клиентского приложения. 32-разрядные версии клиентского приложения будут игнорироваться, даже если среди них есть более свежие версии.

3. Приоритет 32 (x86) ‑ в этом случае приоритет будет отдаваться 32-разрядной версии клиентского приложения. Но если среди 64-разрядных клиентских приложений существует более свежая версия ‑ будет использоваться самая свежая версия (она будет 64-разрядная).

4. Приоритет 64 (x86-64) ‑ в этом случае приоритет будет отдаваться 64-разрядной версии клиентского приложения. Но если среди 32-разрядных клиентских приложений существует более свежая версия ‑ будет использоваться самая свежая версия (она будет 32-разрядная).

5. Автоматически ‑ это равноценно тому, что разрядность запускаемого клиентского приложения не определена явным образом. В этом случае будет использован вариант Приоритет 32 (x86).

Следует отметить, что работоспособность системы не зависит от разрядностей (операционной системы и используемого процессора) клиентских приложений или кластера серверов (для клиент-серверного варианта системы). Это означает, что в один момент времени, с информационной базой могут работать клиентские приложения разной разрядности, на разных процессорах и под управлением различных операционных систем. В клиент-серверной системе разрядность кластера серверов может не совпадать с разрядностью, операционной системой и используемым процессором клиентских приложений. Разрядность исполняемого приложения, а также операционная система, под управлением которой исполняется приложение, важны в следующих случаях:

● Использование COM-соединения (только для ОС Windows).

● Использование внешних компонент ‑ внешняя компонента должна включать файл внешней компоненты, характеристики которого соответствуют тому приложению, в котором планируется использовать внешнюю компоненту. Внешняя компонента содержит манифест, который описывает, для каких вариантов запуска разработчик внешней компоненты собрал внешнюю компоненту. Подробнее о манифесте внешней компоненты написано на Портале 1С:ИТС (https://its.1c.ru/db/metod8dev#content:3221:hdoc). Для всех окружений, где поддерживается использованием внешних компонент.

Смотри также:

● Настройки окна запуска (см. здесь).

● Ключи командной строки (см. здесь).

● 1cestart.cfg (см. здесь).

● 1cescmn.cfg (см. здесь).

● *.v8i (см. здесь).

В случае клиент-серверной системы, версия клиентского приложения может отличаться от версии серверного приложения. Работать в этом случае невозможно ‑ версии клиента и сервера должны в точности совпадать.

Рис. 23. Несовпадение версии клиента и сервера

Клиентское приложение (тонкий или толстый клиент) в случае несовпадения версии клиента и сервера выполняет попытку поиска и установки версии, которая требуется для работы с сервером. Поиск дистрибутива клиентского приложения выполняется в следующем порядке:

● В каталоге, куда установлено «1С:Предприятие» (свойство InstalledLocation файлов 1cestart.cfg и 1cescmn.cfg);

● В каталогах, указанных как место расположения дистрибутивных файлов новых версий (свойство DistributiveLocation файлов 1cestart.cfg и 1cescmn.cfg, а также свойство CommonCfgLocation файла 1cestart.cfg);

● По URL, который возвращается в серверном исключении о несовпадении версий клиентского и серверного приложения (параметр PublishDistributiveLocation* файла conf.cfg и атрибут pubdst* элемента ws файла default.vrd);

● С помощью интернет-сервисов получения дистрибутива клиентского приложения.

При этом надо помнить, что:

● Поиск и получение дистрибутива с помощью интернет-сервисов осуществляется тонким клиентом, только в том случае, если подключение к информационной базе осуществляется по HTTP-соединению.

● Получение дистрибутива через URL, указанный в исключение о несовпадении версии клиента и сервера, осуществляется тонким клиентом при любом клиент-серверном подключении.

● Если в списке информационных баз (файл *.v8i) указана версия, которую невозможно установить, то будет выполнена попытка запуска информационной базы с помощью максимальной версии, доступной на текущем компьютере. В этом случае путь к дистрибутиву нужного клиентского приложения может быть получен от сервера «1С:Предприятия».

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

Для запуска веб-клиента нужно запустить веб-браузер и набрать URL доступа к информационной базе. При этом веб-браузер должен быть особым образом настроен. Подробности настройки см. здесь. Одна и та же информационная база (одинаковый URL) может быть открыта в разных закладках одного веб-браузера.

Информацию по настройке веб-серверов для работы с веб-клиентом см. здесь.

Язык интерфейса веб-клиента можно указать следующими способами (в порядке повышения приоритета):

● в настройках предпочтительных языков веб-браузера;

● в командной строке (параметр L).

При выборе языка интерфейса выполняются следующие действия:

● При обработке запроса к ресурсу, которому соответствует информационная база (например, http://localhost/demo), производится выбор языка локализации:

● При наличии в URL параметра L анализируется значение данного параметра. Например: http://localhost/demo?l=en для указания английского языка локализации. Если в результате анализа параметра язык не подобран, производится анализ заголовка Accept-Language.

● При отсутствии параметра в URL производится анализ стандартного заголовка HTTP ‑ Accept-Language (который содержит предпочтительные языки, установленные в браузере).

● Выбор доступного языка осуществляется из набора установленных на веб-сервере локализаций:

● Если точного соответствия не найдено (например, в параметре указан язык en_US), производится усечение имени языка и выполняется повторный поиск (в примере: en).

● Если соответствующий язык не был найден в процессе анализа, языком по умолчанию является английский (en):

● Выбранный язык добавляется к базовому URL приложения (в примере получается: http://localhost/demo/en), и осуществляется автоматическая переадресация веб-браузера на новый URL.

Региональные установки сеанса веб-клиента (влияющие на отображение значений типа Число и Дата) можно указать следующими способами (в порядке повышения приоритета):

● в настройках предпочтительных языков веб-браузера;

● в командной строке (параметр VL).

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

● При наличии в URL параметра VL используются региональные установки, соответствующие локализации, код которой указан в параметре. Например: http://localhost/demo?vl=en для указания региональных установок сеанса для английского языка. Если в качестве значения параметра указан код несуществующей локализации, работа веб-клиента завершается с ошибкой.

● При отсутствии параметра в URL производится анализ стандартного заголовка HTTP ‑ Accept-Language (который содержит предпочтительные языки, установленные в браузере).

Возможны ситуации, когда необходимо запустить «1С:Предприятие», минуя стандартное окно аутентификации пользователей. Это может потребоваться, когда аутентификацию в «1С:Предприятии» необходимо сделать либо через специализированную форму (например, интегрированную в какой-либо веб-сайт), либо логин и пароль входа в информационную базу хранятся в отдельной базе данных.

Для реализации этих требований существует возможность выполнять аутентификацию сеанса веб-клиента с помощью POST-запроса к специальному ресурсу информационной базы: e1cib/start. В этом случае процесс запуска можно представить следующим образом:

1. Выполняется POST-запрос с целью аутентификации клиента.

2. Если аутентификация выполнена успешно, то от лица переданного в POST-запросе пользователя создается сеанс.

3. Выполняется запуск веб-клиента, в командную строку которого передаются следующие параметры из POST-запроса: LowClientConnectionSpeed, LaunchParameter, LocaleCode, Zone.

4. Запущенный веб-клиент подключается к аутентифицированному (на шаге 2) сеансу.

В запросе передаются следующие параметры:

Имя пользователя.

Пароль пользователя.

Значение по умолчанию ‑ пустая строка.

Скорость соединения.

Возможные значения:

● on ‑ низкая скорость соединения.

● off ‑ нормальная скорость соединения (значение по умолчанию).

Параметры, которые необходимо передать в прикладное решение (аналог параметра C командной строки веб-клиента).

Значение по умолчанию ‑ пустая строка.

Язык интерфейса. Если не задано ‑ определение языка интерфейса и региональных установок, см. здесь.

Язык интерфейса. Если не задано ‑ определение языка интерфейса и региональных установок, см. здесь.

Значения разделителей. Подробную информацию о задании значений разделителей в веб-клиенте можно получить в книге.

Определяет поведение системы в случае ошибки аутентификации. Возможные значения:

● error ‑ возвращает код ошибки (код ошибки ‑ 402) и текст сообщения об ошибке.

● start ‑ выполняется запуск веб-клиента с запросом аутентификации средствами «1С:Предприятия».

● redirect ‑ осуществляется переход на URL, заданный параметром AuthFailRedirectURL.

Значение по умолчанию ‑ error.

Содержит URL, на который следует перейти в случае ошибки аутентификации, если параметр AuthFailHandling установлен в значение redirect. URL должен быть абсолютным.

Пример:

Ниже приведен пример HTML-страницы, который демонстрирует работу собственной формы аутентификации для информационной базы, расположенной по адресу http://localhost/demoapp.

<HTML xmlns="http://www.w3.org/1999/xhtml"><HEAD>
<META http-equiv="Content-Type" content="text/html; charset=utf-8" />
<BODY>
<FORM action="http://localhost/demoapp/e1cib/start" method="post">
    Пользователь: <INPUT id="usr" name="usr" /><BR />
    Пароль: <INPUT id="pwd" type="password" value="" name="pwd" />
    <BR />Низкая скорость: <INPUT id="lowclientconnectionspeed" type="checkbox" name="lowclientconnectionspeed" /><BR />
    Параметр запуска: <INPUT id="launchparameter" name="launchparameter" /><BR />
    Язык интерфейса: <SELECT id="systemlanguage" name="systemlanguage">
   <OPTION value="ru" selected="">Русский</OPTION>
   <OPTION value="en">Английский</OPTION>
    </SELECT><BR />
    Код локализации сеанса: <SELECT id="localecode" name="localecode">
   <OPTION value="ru" selected="">Русский</OPTION>
   <OPTION value="en">Английский</OPTION>
    </SELECT><BR />
    Область данных: <INPUT id="zone" name="zone" />
    <INPUT id="authfailhandling" type="hidden" value="error" name="authfailhandling" />
    <P><INPUT type="submit" value="ОК" /> </P>
</FORM>
</BODY>
</HTML>

В результате будет показана следующая форма аутентификации:

Рис. 24. Форма POST-запроса

Если для выбранной информационной базы существует список пользователей, которым разрешена работа с ней (создание и редактирование такого списка выполняется в конфигураторе системы «1С:Предприятие»), на экран будет выдан диалог аутентификации пользователя в информационной базе. В верхней части диалога, под логотипом «1С», расположено название информационной базы, доступ к которой пытается получить пользователь. Такое имя отображается в том случае, если диалог аутентификации открывается из программы запуска, в список информационных баз которой добавлена текущая база. Если доступ к информационной базе осуществляется с помощью веб-клиента или с указанием параметров доступа в командной строке запуска клиентского приложения, то под логотипом «1С» выводится текст «1С:Предприятие».

Рис. 25. Аутентификация пользователя

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

● Щелкнуть мышью в поле Пользователь и выбрать имя из списка. Данный способ можно использовать, если в настройках есть пользователи, которых можно отображать в списке выбора.

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

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

Рис. 26. Последние пользователи

Если пользователю назначен пароль, его следует ввести в поле Пароль. После указания имени и пароля пользователя процесс запуска продолжится, если нажать кнопку Войти. Для закрытия окна аутентификации (и отказа от подключения к информационной базе) следует нажать кнопку «X» (в правом верхнем углу диалога).

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

Рис. 27. Скрытый пароль

Нажатие на кнопку приводит к тому, что пароль отображается открытым текстом, не замаскированный символами «*». При этом кнопка меняет свою картинку, как видно на следующем рисунке.

Рис. 28. Открытый пароль

Повторные нажатия на кнопку в поле ввода пароля приводят к тому, что режим поля ввода пароля переключается циклически: пароль отображается «*» ‑ пароль отображается открытым текстом. При повторном открытии диалога аутентификации пользователя, пароль будет вводиться в маскированном режиме.

Если в настройках информационной базы (или в параметрах публикации на веб-сервере) настроено разрешение сохранения аутентификации, то диалог аутентификации выглядит следующим образом:

Рис. 29. Запомнить аутентификацию

Если в диалоге аутентификации установить флажок Запомнить, то при следующей аутентификации в указанную информационную базу, на данном компьютере, не будет выполняться попытка аутентификации пользователя, а будет сразу выполняться вход от имени пользователя, который был указан в диалоге перед тем, как установить флажок (в примере на рисунке это будет пользователь Администратор (ОрловАВ)). Подробнее о настройке режима запоминания аутентификации см. здесь.

Если в информационной базе включена возможность самостоятельного восстановления пароля пользователей, то в диалоге будет отображаться гиперссылка Забыли пароль?.

Рис. 30. Восстановление пароля

При нажатии на гиперссылку будет запущен механизм восстановления пароля пользователя (подробнее о настройке и использовании механизма см. здесь).

Если для информационной базы настроено несколько различных видов аутентификации, то диалог аутентификации отображает все настроенные виды аутентификации.

Рис. 31. Варианты аутентификации

Виды аутентификации отображаются в нижней части диалога, которая озаглавлена Войти через…. Отдельно отображается возможно аутентификации с помощью QR-кода. Если такая возможность включена, то она отображается под кнопкой Войти с помощью гиперссылки Войти через QR-код. В диалоге аутентификации отображаются следующие виды аутентификации: стандартная, через электронную почту, аутентификация с помощью QR-кода, аутентификация OpenID и аутентификация OpenID Connect. Может быть настроено (и, соответственно, будет отображаться) использование нескольких провайдеров аутентификации OpenID Connect. Активная аутентификация (параметры которой отображаются в верхней части диалога) выделена подчеркиванием под картинкой, связанной с аутентификацией.

Для того, чтобы в диалоге аутентификации отображались доступные пользователю виды аутентификации, должны быть выполнены следующие условия:

● Вид аутентификации должен быть настроен для данной информационной базы.

● Для данной информационной базы должна быть включена возможность выбрать для использования вид аутентификации.

Все вышеупомянутые настройки выполняются с помощью конфигурационного файла настройки публикации default.vrd. Элементы <openid> и <openidconnect> служат для настройки аутентификации OpenID и OpenID Connect. Элемент <mobileApps> служит для указания размещения мобильных приложений, которые могут использоваться для входа по QR-коду. Элемент <authentication> предназначен для отображения того или иного вида аутентификации, а также для указания порядка следования настроенных видов аутентификации в диалоге аутентификации. Нужно понимать, что скрытие вида аутентификации в элементе <authentication> имеет более высокий приоритет, чем настройки, выполненные в других разделах файла default.vrd. Так, если в файле default.vrd настроена OpenID аутентификация (и провайдер доступен клиентскому приложению), а в элементе <authentication> OpenID-аутентификация выключена, то OpenID-аутентификацию будет нельзя выбрать в диалоге аутентификации данной информационной базы. Также надо понимать, что включение отображения какого-либо вида аутентификации (элемент <authentication>) не приведет к автоматической настройке этого вида аутентификации.

Если в настройках аутентификации OpenID Connect для провайдера указан картинка (поле image описания провайдера), то в диалоге аутентификации провайдер будет отображаться именно этой картинкой. В качестве подсказки для провайдера OpenID Connect будет отображаться содержимое поля title описания провайдера.

Если в процессе аутентификации пользователя при запуске клиентского приложения (тонкий клиент, веб-клиент, мобильный клиент, толстый клиент, конфигуратор) возникает одна из ошибок доступа (нет свободной лицензии, запрет от сервиса внешнего управления сеансами или ошибке монопольного доступа к информационной базе/области), то система выполняет следующие действия:

1. Если в текущей информационной базе/области нет других сеансов аутентифицирующегося пользователя, то пользователю отображается ошибка. Клиентское приложение не запускается.

2. Если в текущей информационной базе/области существуют другие сеансы аутентифицирующегося пользователя, соответствующие клиентские приложения были запущены на том же клиентском компьютере и уже завершились, то сеансы завершаются автоматически и выполняется повторная попытка аутентификации.

3. Иначе (если в текущей информационной базе/области существуют сеансы аутентифицирующегося пользователя, но их клиентские приложения ещё работают или запущены на другом клиентском компьютере) пользователю отображается диалог со списком сеансов этого пользователя и предложением завершить эти сеансы или некоторые из них. Если пользователь согласен с предложением, то выполняется попытка завершения выбранных сеансов и повторная попытка аутентификации.

Смотри также:

● Описание файла default.vrd (см. здесь).

Перед тем, как получить доступ к данным информационной базы, клиентское приложение должно указать, от имени какого пользователя информационной базы будет выполняться доступ к данным, а также пройти проверку подлинности указанного пользователя. Причем совершенно неважно, что выступает в роли «клиентского приложения» ‑ собственно клиентское приложение системе «1С:Предприятие» или любой программный продукт, который пытается получить доступ к данным через внешние интерфейсы прикладного решения. Доступ к данным может выполняться несколькими способами: с помощью прямого доступа к файловой информационной базе или серверу «1С:Предприятие» (выполняется по протоколу TCP/IP) или доступ с помощью веб-сервера (протокол HTTP(s)). Клиентское приложение может проходить аутентификацию следующими способами:

1. С помощью имени пользователя и пароля (аутентификация средствами «1С:Предприятия», стандартная аутентификация). В рамках данного способа аутентификации возможно применение двухфакторной аутентификации (если она настроена на стороне системы «1С:Предприятие»). Подробнее о двухфакторной аутентификации см. здесь. Подробнее об аутентификации средствами «1С:Предприятия» см. здесь.

2. С помощью аутентификации операционной системы. Подробнее см. здесь.

3. С помощью протоколов OpenID и OpenID Connect. Провайдеры OpenID могу использовать различные виды двухфакторной аутентификации. Эта возможность зависит от настроек этих провайдеров. Подробнее см. здесь и см. здесь.

4. С помощью специального токена доступа. Подробнее см. здесь.

5. Аутентификация с помощью QR-кода. Подробнее см. здесь.

6. Аутентификация через электронную почту. Подробнее см. здесь.

В зависимости от того, каким образом выполняется доступ к данным «1С:Предприятия», могут использоваться и различные виды аутентификации.

Самым простым, с точки зрения видов аутентификации и участвующих компонентов системы, является прямой доступ к файловой информационной базе или кластеру серверов «1С:Предприятие». В этом случае нам необходимо использовать только доступ непосредственно к информационной базе, без привлечения каких-либо промежуточных (вспомогательных) серверов.

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

● Аутентификация операционной системы.

● Аутентификация средствами «1С:Предприятие».

● Аутентификация через электронную почту (только для интерактивной аутентификации).

Если подключение выполняется с использованием протокола HTTP(s), то в процессе установки соединения участвуют два дополнительных участника:

● Прокси-сервер ‑ это сервер, который выступает в качестве посредника между клиентским приложением и целевым сервером. При этом будем считать, что прокси-сервер расположен в компьютерной сети клиентского приложения.

● Веб-сервер ‑ это сервер, который организует доступ по протоколу HTTP(s) к информационной базе или кластеру серверов «1С:Предприятие». Будем считать, что веб-сервер расположен в той же компьютерной сети, что и кластер серверов или информационная база.

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

Говоря о процессе доступа, можно упомянуть поддержку протокола HTTPS (или защищенное соединение). Этот протокол не имеет прямого отношения к аутентификации, но защищенное соединение позволяет повысить уверенность в том, что клиент и сервер действительно являются теми субъектами, за которые они себя выдают. Поэтому мы также кратко рассмотрим этот момент в данном разделе. Защищенное соединение организуется между клиентским приложением и веб-сервером, на котором опубликована информационная база системы «1С:Предприятие» и только в том случае, если на веб-сервере включена поддержка протокола HTTPS для требуемой информационной базы. Указание, что клиентское приложение должно использовать защищенное соединение, выполняется следующим образом:

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

● При использовании тонкого клиента, настройки использования сертификатов выполняются с помощью интерактивной программы запуска. При настройке можно указать, каким образом будет проверяться сертификат веб-сервер и какой сертификат будет предъявлять клиентское приложение.

● При работе из встроенного языка, защищенное соединение настраивается с помощью объекта ЗащищенноеСоединениеOpenSSL, параметры которого аналогичны настройкам интерактивной программы запуска.

Таким образом, в самом полном случае, в процессе аутентификации участвует четыре элемента: клиентское приложение (расположенное на клиентском устройстве), прокси-сервер, веб-сервер и кластер серверов «1С:Предприятие» (или расширение веб-сервера для файлового варианта информационной базы).

Рис. 32. Варианты аутентификации

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

1. Аутентификация на прокси-сервере.

● Для аутентификации могут использоваться:

● Аутентификация средствами «1С:Предприятие».

● Аутентификация операционной системы.

● Параметры аутентификации на прокси-сервере указываются:

● В настройках доступа к информационной базе в интерактивной программе запуска.

● С помощью параметра командной строки запуска клиентского приложения /Proхy.

● С помощью объекта ИнтернетПрокси в случае программного доступа к данным.

● С помощью конфигурационного файла inetcfg.xml.

2. Аутентификация на веб-сервере.

● Для аутентификации могут использоваться:

● Аутентификация средствами «1С:Предприятие».

● Аутентификация операционной системы.

● Параметры аутентификации на веб-сервере указываются:

● С помощью параметра командной строки запуска клиентского приложения /WSA, /WSN и /WSP.

● С помощью объекта ИнтернетПрокси в случае программного доступа к данным.

● Может использоваться защищенное соединение (протокол HTTPS).

3. Аутентификация в информационной базе.

● Для аутентификации могут использоваться:

● Токен доступа.

● Аутентификация операционной системы.

● Аутентификация различными вариантами протокола OpenID.

● QR-код.

● Имя пользователя и пароль.

● Аутентификация через электронную почту (только интерактивный вход).

● Параметры аутентификации для информационной базы указываются:

● Токен доступа:

● С помощью параметра командой строки запуска клиентского приложения /AccessToken.

● С помощью параметра строки соединения с информационной базой AccessToken.

● С помощью заголовка HTTP-запроса к информационной базе Authorization: Bearer.

● Аутентификация операционной системы:

● С помощью параметра командной строки запуска клиентского приложения /WA. Допустимо только включение/выключение данного способа аутентификации.

● С помощью параметра ИспользоватьАутентификациюОС конструкторов объектов HTTPСоединение или WSОпределения.

● Аутентификация с помощью OpenID:

● С помощью параметра командной строки запуска клиентского приложения /OIDA. Допустимо только включение/выключение данного способа аутентификации. Параметры аутентификации определяются настройками публикации информационной базы, к которой будет выполняться доступ.

● С помощью заголовка HTTP-запроса к информационной базе Authorization: Bearer.

● С помощью имени пользователя и пароля:

● С помощью параметров командной строки запуска клиентского приложения /N и /P.

● С помощью параметров строки соединения с информационной базой.

● С помощью заголовка HTTP-запроса к информационной базе Authorization: Basic.

● Аутентификация через электронную почту:

● С помощью параметра командной строки запуска клиентского приложения /EmailAuth.

Смотри также:

● Параметры командной строки запуска (см. здесь).

● Виды аутентификации в системе «1С:Предприятие» (см. здесь).

● Способы интеграции в системе «1С:Предприятие» (см. здесь).

Аутентификация на веб-сервере, при интерактивном доступе к информационной базе, выполняется следующим образом:

● Тонкий клиент:

● Указан параметр /WSA- ‑ выполняется интерактивный запрос имени пользователя и пароля для аутентификации на веб-сервере.

● Указаны корректные параметр /WSN и /WSP ‑ выполняется аутентификация на веб-сервере от указанного пользователя.

● Параметр /WSN не задан ‑ выполняется аутентификация ОС, в случае неудачи выполняется запрос имени пользователя и пароля.

● Параметр /WSN задан и не задан параметр /WSP (или задан некорректно) ‑ выполняется интерактивный запрос имени пользователя и пароля для аутентификации на веб-сервере.

● Веб-клиент:

● Данным процессом управляет веб-браузер.

Смотри также:

● Параметры командной строки запуска (см. здесь).

● Виды аутентификации в системе «1С:Предприятие» (см. здесь).

Аутентификация в информационной базе в случае непосредственного соединения с сервером/информационной базой (тонкий и толстый клиенты) или в случае соединения с информационной базой через веб-сервер (тонкий клиент или веб-клиент) выглядит следующим образом:

Рис. 33. Процесс интерактивной аутентификации

Во время этого процесса выполняются действия в следующем порядке:

1. Выполняется аутентификация токеном сохраненной аутентификации, если возможно.

2. Выполняется аутентификация с помощью JWT, если возможно.

Если аутентификация не выполнена ‑ дальнейшие способы аутентификации не выполняются.

3. Выполняется аутентификация операционной системы, если возможно.

Если аутентификация выполнена неудачно или указана команда /WA-, то продолжаются попытки выполнить другие виды аутентификации.

4. Выполняется аутентификация с использованием имени пользователя и пароля (если в командной строке указан один или оба параметра аутентификации):

● При указании корректных параметров /N и /P ‑ выполняется аутентификация от имени указанного пользователя.

● Если параметр /N не задан ‑ выполняется запрос имени и пароля пользователя.

● Если параметр /P не задан или задан некорректно ‑ производится попытка аутентификации (если параметр не задан ‑ выполняется попытка аутентификации с пустым паролем), в случае неудачи выполняется запрос имени пользователя и пароля (окно аутентификации).

● Если попытка аутентификации неудачна и указан параметр /N, то в открывшемся окне аутентификации значение параметра /N будет указано в поле имени пользователя.

5. Пользователь выбирает в диалоге требуемый способ аутентификации и выполняет попытку аутентифицироваться этим способом. Диалог аутентификации настраивается с помощью файла описания публикации default.vrd (элемент <authentication>). В том случае, если в файле default.vrd отключен какой-либо вид аутентификации ‑ пользователь не сможет выбрать этот вид аутентификации в диалоге, несмотря на то что остальные настройки присутствуют и выполнены корректно. Если в командной строке указан параметр /OIDA-, то аутентификация с помощью OpenID будет недоступна для выбора.

Смотри также:

● Параметры командной строки запуска (см. здесь).

● Виды аутентификации в системе «1С:Предприятие» (см. здесь).

При программном доступе к информационной базе, аутентификация на веб-сервере настраивается с помощью объектов HTTPСоединение или WSОпределения (в зависимости от используемого вида сервиса):

● Аутентификация на веб-сервере определяется параметрами ИмяПользователя, Пароль и ИспользоватьАутентификациюОС конструкторов объектов HTTPСоединение и WSОпределения:

● Параметр ИспользоватьАутентификациюОС установлен в значение Истина:

● В настройках веб-сервера включена аутентификация операционной системы:

● Выполняется аутентификация операционной системы.

● Если указаны параметры ИмяПользователя и Пароль, то значения этих параметров используются для выполнения аутентификации по протоколам NTLM и Kerberos. ИмяПользователя должно быть указано в виде DOMAIN\user или user@domain.

● Если параметры ИмяПользователя и Пароль не будут указаны, то будут использованы параметры пользователя, от имени которого исполняется текущий сеанс.

● В настройках веб-сервера не включена аутентификация операционной системы:

● Аутентификация на веб-сервере не выполняется.

● Для доступа к информационной базе будут использовать ИмяПользователя и Пароль.

● Параметр ИспользоватьАутентификациюОС установлен в значение Ложь:

● Если указано ИмяПользователя и Пароль, то выполняется аутентификация с использованием имени пользователя и пароля.

● Не рекомендуется указывать имя пользователя и пароль доступа к информационной базе, которые указаны в URL доступа к информационной базе. В некоторых случаях это может приводить к различным труднодиагностируемым ошибкам.

Смотри также:

● Виды аутентификации в системе «1С:Предприятие» (см. здесь).

● Способы интеграции в системе «1С:Предприятие» (см. здесь).

После того, как выполнена аутентификации на веб-сервере, расширение веб-сервера выполняет попытку аутентификации в информационной базе:

● Если указан заголовок HTTP-запроса Authorization: Bearer ‑ выполняется попытка выполнить аутентификацию с использованием токена доступа. Если попытка неудачная ‑ доступ к информационной базе невозможен.

● Если указан заголовок HTTP-запроса Authorization: Basic ‑ выполняется попытка выполнить аутентификацию с имени пользователя и пароля.

● Если стандартные заголовки не используются, то расширение веб-сервера выполняет попытку получения имени пользователя и пароля из строки соединения с информационной базой из файла default.vrd. Если параметры определены ‑ для их передачи используются служебные заголовки запроса.

● Если имя пользователя и пароль определить не получилось, то выполняется попытка использовать аутентификацию операционной системы. Если попытка выполнить аутентификация операционной системы была неудачно ‑ доступ к информационной базе невозможен.

Смотри также:

● Виды аутентификации в системе «1С:Предприятие» (см. здесь).

● Способы интеграции в системе «1С:Предприятие» (см. здесь).

При работе через публичные каналы связи (Интернет) большое значение приобретает возможность защиты информации, передаваемой по этому каналу, от перехвата и подмены. Рассмотрим организацию такого соединения в системе на базе «1С:Предприятие».

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

Чтобы получить представление о работе этой инфраструктуры, обратимся к простому примеру. Представим, что мы находимся в некоем мире, где любой человек может проверить удостоверение другого человека в ведомстве, которое это удостоверение выдало.

В этом мире один человек (Прохожий) встречает другого человека (Полицейского), который хочет удостовериться в том, что человек перед ним ‑ действительно Прохожий. Для этого Полицейский просит у Прохожего его паспорт. Прежде чем предъявлять свои документы, Прохожий хочет убедиться, что перед ним реальный Полицейский. Он просит у Полицейского его удостоверение личности, связывается с Министерством Управления Полиции и по номеру проверяет, что человек перед ним ‑ действительно тот, за кого он себя выдает, т. е. Полицейский. После успешной процедуры аутентификации Прохожий отдает свой паспорт Полицейскому. В паспорте написано, что он выдан Министерством Выдачи Документов и указан номер паспорта. Полицейский связывается с Министерством и с помощью номера паспорта удостоверяется в том, что человек перед ним ‑ действительно Прохожий.

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

Теперь представим эту простую схему с точки зрения объектов PKI и сетевой инфраструктуры. Клиентское приложение «1С:Предприятия» выступает в роли Прохожего. Веб-сервер, с помощью которого клиентское приложение хочет получить доступ к информационной базе, выступает в роли Полицейского. Министерство Выдачи Документов и Министерство Управления Полицией играют роль Удостоверяющих Центров. Сертификат, используемый при установке HTTPS-соединения, представлен в виде паспорта Прохожего и удостоверения личности Полицейского.

Теперь вся схема выглядит следующим образом: при попытке клиентского приложения подключиться к веб-серверу, происходит проверка клиентским приложением сертификата сервера. Проверка выполняется с помощью удостоверяющего центра, который указан в сертификате веб-сервера (если этот удостоверяющий центр присутствует в списке корневых удостоверяющих центров на компьютере, где установлено клиентское приложение). Если проверка прошла успешно, то клиентское приложение предъявляет свой сертификат (клиентский сертификат) для проверки веб-серверу. Сервер выполняет проверку с помощью своего списка корневых удостоверяющих центров. Если проверка прошла успешно ‑ клиентское приложение и веб-сервер устанавливают между собой защищенное соединение (HTTPS-соединение). При этом клиентское приложение шифрует передаваемые данные с помощью открытого ключа сервера (и расшифровывает данные, полученные от сервера), а сервер ‑ шифрует и расшифровывает данные с помощью своего закрытого ключа. Очевидно, что закрытые ключ клиентского приложения и веб-сервера ‑ не совпадают и неизвестны сторонам.

Выше приведена общая схема установки защищенного соединения. Более подробно эти схемы будут описаны в следующем разделе.

Защищенное соединение может быть установлено между тонким клиентом или веб-клиентом и веб-сервером, посредством которого выполняется подключение к информационной базе. Существует несколько схем установки такого соединения (в зависимости от наличия тех или иных сертификатов на обеих сторонах соединения), которые будут рассмотрены ниже. Нужно помнить, что при любой установке HTTPS-соединения, оно будет зашифровано.

В таблице использованы следующие термины:

● Сертификат ‑ означает наличие (Сертификат+) или отсутствие (Сертификат-) соответствующего сертификата:

● Для сервера ‑ серверного сертификата.

● Для клиента ‑ клиентского сертификата.

● Корневые ‑ означает наличие (Корневые+) или отсутствие (Корневые-) списка сертификатов удостоверяющих центров (УЦ или CA), с помощью которых можно проверить предъявленный сертификат. Список удостоверяющих центров должен позволять проверить сертификат, предоставленный клиентским приложением или веб-сервером.

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

Для тонкого клиента сертификат (и списки корневых сертификатов) можно указать с помощью параметров командной строки запуска или с помощью параметров запуска информационной базы (см. здесь).

В качестве источников сертификатов могу выступать следующие хранилища:

● Системное хранилище сертификатов ‑ для ОС macOS и Windows.

● Хранилище сертификатов ОС Linux, расположенное в каталоге /etc/ssl/certs. Все сертификаты, расположенные в этом каталоге, считаются доверенными.

На некоторых дистрибутивах ОС Linux поддерживаются также следующие каталоги расположения корневых сертификатов:

● Debian, Mint, Ubuntu ‑ каталог /etc/ssl/certs/ca-certificates.crt.

● CentOS, Fedora, RedHat ‑ каталог /etc/ssl/certs/ca-bundle.trusted.crt или /etc/pki/tls/certs/ca-bundle.crt.

● Alt Linux ‑ каталог /etc/share/ca-certificates/ca-bundle.crt.

● Файловые сертификаты ‑ для ОС Linux, macOS и Windows.

Допустимые форматы файловых сертификатов:

● PEM (base-64 encoded X.509) ‑ зашифрованные ключи и сертификаты стандарта X.509 в текстовом формате. Данные сертификатов и ключей кодируются в кодировке base-64. Закрытые ключи сертификатов защищены паролем. Данный формат файлов сертификатов используется по умолчанию, например, веб-сервером Apache. Если закрытый ключ клиентского сертификата хранится в отдельном файле, то необходимо добавить содержимое этого файла к файлу клиентского сертификата.

● P12/PFX (PKCS#12) ‑ зашифрованные ключи и сертификаты стандарта PKCS#12. Файл может быть защищен паролем. Это основной формат экспорта и импорта системных хранилищ сертификатов для ОС Windows. Используется, например, веб-сервером Microsoft Internet Information Services. Файл клиентского сертификата должен содержать его закрытый ключ.

Формат файла выбирается по его расширению:

● *.p12, *.pfx ‑ формат файла P12,

● *.pem ‑ формат файла PEM,

● по умолчанию выбирается формат файла PEM.

Как было отмечено ранее, при использовании протокола TLS необходимо, чтобы обе стороны соединения (клиент и сервер) имели соответствующий сертификат. На стороне сервера должен быть сертификат, который используется для аутентификации сервера. На стороне клиента должен быть сертификат, который используется для аутентификации клиента. Каждый из этих сертификатов должен быть удостоверен доверенным центром сертификации. Если защищенное соединение необходимо использовать в рамках производственных информационных баз, то, очевидно, что сертификаты, используемые в этих случаях, должны быть выданы доверенными удостоверяющими центрами. Кроме того, эти сертификаты должны соответствовать различным регламентам, которые обусловлены национальным законодательством или национальными регуляторами.

Однако, для целей тестирования или для развертывания какой-либо инфраструктуры во внутренней сети (интранете) предприятия, использование сертификатов, выданных доверенным удостоверяющим центром, может оказаться избыточно по разным причинам (стоимость, невозможность быстро выпускать произвольное количество сертификатов и т. д.). В этом случае можно использовать самоподписанные сертификаты. С технической стороны, самоподписанные сертификаты ничем не отличаются от сертификатов, выданных доверенными удостоверяющими центрами. Самоподписанные сертификаты обладают следующими достоинствами:

● Возможность создания бесконечного количества сертификатов.

● Отсутствие платы за создание сертификата.

В тоже время, самоподписанные сертификаты обладают существенными минусами:

● Отсутствие поддержки вашего «удостоверяющего центра» в стороннем программном обеспечении.

● Отсутствие доверия к вашему сертификату со стороны третьих лиц.

● Невозможность отзыва сертификата.

● Повышенный риск потери данных, которые передаются по соединению, защищенным самоподписанными сертификатами.

Однако, несмотря на все минусы, самоподписанные сертификаты логично использовать для нужд тестирования и внутренних систем предприятия, если при использовании самоподписанных сертификатов вышеуказанными рисками можно пренебречь.

Данный раздел будет посвящен созданию следующего набора сертификатов:

● Сертификат корневого удостоверяющего центра.

● Сертификат сервера.

● Клиентский сертификат.

Примеры создания сертификатов будут приведены с использованием двух пакетов: OpenSSL и Java. Результат будет одинаковым, использование разных пакетов направлено на повышение наглядности примеров. Для примера будет создаваться сертификат для домена server.com. Параметры, которые будут указываться при создании сертификатов, следующие:

● Для корневого сертификата

● Country Name: RU

● State or Province Name: Moscow

● Locality Name: Moscow

● Organization Name: Company

● Organizational Unit Name: Department

● Common Name: Root CA

● Email Address: admin@company.site

● Для сертификата сервера:

● Country Name: RU

● State or Province Name: Moscow

● Locality Name: Moscow

● Organization Name: Company

● Organizational Unit Name: Department

● Common Name: server.com

● Email Address: admin@company.site

Эти параметры будет необходимо указывать в консоли, при создании того или иного сертификата.

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

В данном разделе мы создадим сертификат, который будет использоваться для заверения сертификата нашего тестового сервера.

С помощью OpenSSL:

openssl req -x509 -days 3652 -newkey rsa:2048 -keyout root-ca.key -out root-ca.crt

С помощью Java:

keytool -genkey -alias root-ca -keyalg RSA -keystore root-ca.jks -keysize 2048 -startdate 2023/01/01 -validity 3652

В приведенных примерах:

● Сертификат действителен в течение 10 лет.

● Срок действия сертификата будет начинаться:

● Для OpenSSL: с момента генерации сертификата.

● Для Java: с даты, указанной в параметре -startdate.

● Параметры сертификата будет необходимо ввести в консоли, в процессе созданием сертификата.

Обе утилиты вначале запросят пароль, которым будет зашифрован закрытый ключ корневого удостоверяющего центра.

Для получения файла сертификата из хранилища JKS (в случае Java) будет необходимо использовать следующую команду:

С помощью Java:

keytool -exportcert -rfc -keystore root-ca.jks -alias root-ca -file root-ca.crt

В результате исполнения нашего примера, будут созданы:

● Для OpenSSL:

● Файл root-ca.key ‑ закрытый ключ корневого сертификата.

● Файл root-ca.crt ‑ корневой сертификат.

● Для Java:

● Файл root-ca.jks ‑ файл хранилища сертификатов Java (Kava KeyStore).

● Файл root-ca.crt ‑ корневой сертификат.

Используя корневой сертификат, необходимо создать сертификат нашего сервера. Эти действия различаются для OpenSSL и для Java.

Вначале рассмотрим пример использования OpenSSL.

Создадим файл server.ext, который будет находится в каталоге, где будут расположены наши сертификаты. В файле должна быть следующая информация:

authorityKeyIdentifier=keyid,issuer
basicConstraints=CA:FALSE
subjectAltName = @alt_names
[alt_names]
DNS.1 = server.com

Затем выполним следующие команды:

openssl req -newkey rsa:2048 -keyout server.key -out server.csr
openssl x509 -req -CAkey root-ca.key -CA root-ca.crt -in server.csr -out server.crt -CAcreateserial -days 365 -extfile server.ext

В данном примере:

● Первая команда создаст закрытый ключ сертификата сервера (server.key) и файл запроса сертификата. Параметры ключа надо будет ввести во время формирования закрытого ключа, в командной строке.

● Вторая команда создаст сертификат для сервера, который будет заверен корневым сертификатом, который был создан на предыдущем шаге.

● Срок действия сертификата составит 365 дней и этот период начинается с даты создания.

С помощью Java:

keytool -genkey -alias server.com -keyalg RSA -keystore server.jks -keysize 2048
keytool -certreq -keystore server.jks -alias server.com -ext san=dns:server.com -file server.csr
keytool -gencert -rfc -infile server.csr -outfile server.crt -keystore root-ca.jks -alias root-ca -ext honored=all -startdate 2023/01/01 -validity 365

В данном примере:

● Первая команда создаст закрытый ключ сертификата сервера и разместит его в хранилище server.jks. Параметры ключа надо будет ввести во время формирования закрытого ключа, в командной строке.

● Вторая команда создаст запрос на сертификат для сервера server.com.

● Третья команда создаст сертификат для сервера, который будет заверен корневым сертификатом, который был создан на предыдущем шаге.

● Срок действия сертификата составит 365 дней и этот период начинается с даты, указанной в параметре -startdate.

Для получения закрытого ключа сервера следует использовать следующую последовательность действий (потребуется пакет OpenSSL):

keytool -importkeystore -srckeystore server.jks -destkeystore server.p12 -deststoretype PKCS12
openssl pkcs12 -in server.p12 -nocerts -nodes -out server.key

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

Создание клиентских сертификатов выполняется по аналогии с созданием серверного сертификата. Эти действия различаются для OpenSSL и для Java.

Вначале рассмотрим пример использования OpenSSL.

Создадим файл client.ext, который будет находится в каталоге, где будут расположены наши сертификаты. В файле должна быть следующая информация:

authorityKeyIdentifier=keyid,issuer
basicConstraints=CA:FALSE

Затем выполним следующие команды:

С помощью OpenSSL:

openssl req -newkey rsa:2048 -keyout client.key -out client.csr
openssl x509 -req -CAkey root-ca.key -CA root-ca.crt -in client.csr -out client.crt -CAcreateserial -days 365 -extfile client.ext

В данном примере:

● Первая команда создаст закрытый ключ сертификата клиента (client.key) и файл запроса сертификата. Параметры ключа надо будет ввести во время формирования закрытого ключа, в командной строке.

● Вторая команда создаст сертификат для клиента, который будет заверен корневым сертификатом (создание корневого сертификата см. здесь).

● Срок действия сертификата составит 365 дней и этот период начинается с даты создания.

С помощью Java:

keytool -genkey -alias client -keyalg RSA -keystore client.jks -keysize 2048
keytool -certreq -keystore client.jks -alias client -file client.csr
keytool -gencert -rfc -infile client.csr -outfile client.crt -keystore root-ca.jks -alias root-ca -ext honored=all -startdate 2023/01/01 -validity 365

В данном примере:

● Первая команда создаст закрытый ключ сертификата клиента и разместит его в хранилище client.jks. Параметры ключа надо будет ввести во время формирования закрытого ключа, в командной строке.

● Вторая команда создаст запрос на сертификат для клиента.

● Третья команда создаст сертификат для клиента, который будет заверен корневым сертификатом (создание корневого сертификата см. здесь).

● Срок действия сертификата составит 365 дней и этот период начинается с даты, указанной в параметре -startdate.

Сертификат содержит в себе открытый ключ соответствующего объекта и различная вспомогательная информация (срок действия сертификата и т. д.). Сертификат используется для установки на компьютер пользователя. Это публичная информация.

Установку самоподписанных сертификатов на веб-сервер следует выполнять в соответствии с документацией к используемому веб-серверу.

Если доступ к информационной базе по защищенному соединению выполняется с помощью веб-клиента, то необходимо на клиентском компьютере указать веб-браузеру, что для проверки серверного сертификата можно использовать самоподписанный сертификат удостоверяющего центра (root-ca.crt). Для этого может оказаться достаточным импортировать этот сертификат в личное хранилище сертификатов компьютера, с которого выполняется доступ.

Если информационная база опубликована на веб-сервере, на который установлен самоподписанный сертификат, то для того, чтобы тонкий клиент подключался к этой информационной базе, необходимо выполнить следующие настройки:

● В качестве пути к базе указать URL на веб-сервере, использующий схему HTTPS.

● В дополнительных настройках подключения:

● В группе Выберите клиентский сертификат следует указать значение Файл сертификата и выбрать файл client.crt. Для организации защищенного соединения между тонким клиентом и веб-сервером, на котором опубликована информационная база, указывать данный сертификат не требуется.

● В группе Выберите способ проверки сертификата сервера следует указать значение Файл сертификатов CA и выбрать файл root-ca.crt.

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

● Открыть список Сертификаты для работы по HTTPS и загрузить туда сертификаты client.crt и root-ca.crt. При этом для второго сертификата указать флажок Для проверки сертификата сервера.

● При настройке списка приложений, указать в поле Адрес веб-сервера URL на веб-сервере, использующий схему HTTPS.

● В поле Способ проверки сертификата сервера выбрать Указанный сертификат. В поле Сертификат сервера выбрать элемент, соответствующий файлу root-ca.crt.

● В поле Клиентский сертификат выбрать сертификат, соответствующий файлу client.crt. Для организации защищенного соединения между мобильным клиентом и веб-сервером, на котором опубликована информационная база, указывать данный сертификат не требуется.

Для того, чтобы собственный сервер системы взаимодействия использовал защищенное соединение (протокол WSS) необходимо соответствующим образом настроить сервер взаимодействия (https://its.1c.ru/db/csdoc/bookmark/cs/TI000000020). В качестве значения <cs_keystore_path> должен выступать полный путь к файлу server.jks.

Существует ряд ситуаций, когда клиентское приложение не может получить доступ к информационной базе. Система уведомляет об этом пользователя и предлагает повторить попытку соединения с информационной базой через 60 секунд. К таким ситуациям относятся:

● При попытке запуска Конфигуратора обнаруживается, что конфигуратор уже запущен данной информационной базы.

● Для информационной базы установлен монопольный режим работы.

● Различаются версии клиентского приложения и сервера «1С:Предприятия».

● Не обнаружен сервер «1С:Предприятия».

● Не обнаружен сервер баз данных.

● Установлен запрет соединения с информационной базой:

● Блокировка начала сеансов с помощью командной строки запуска клиентского приложения, консоли кластера или метода встроенного языка УстановитьБлокировкуСеансов().

● Сервис внешнего управления сеансами.

При обнаружении невозможности подключения к информационной базе, система «1С:Предприятие» выводит диалог, в котором сообщается о причине (в приведенном на рисунке ниже примере это факт открытия данной информационной базы конфигуратором), и предлагается выбрать автоматический перезапуск системы через 1 минуту или отказаться от запуска.

Рис. 34. Ожидание перезапуска

В данном диалоге текст с описанием ситуации может выводиться как простым текстом, так и форматированным текстом. Система «1С:Предприятие» пытается отобразить описание ситуации как форматированную строку в следующих случаях:

● Для информационной базы установлен монопольный режим. В этом случае описание ситуации будет выводиться форматированной строкой, если при установке монопольного режима текст сообщения задан значением типа ФорматированнаяСтрока. Подробнее про установку монопольного режима см. здесь.

● Установлена блокировка начала сеансов с помощью метода УстановитьБлокировкуСеансов(). Описание ситуации будет выводиться форматированной строкой, если параметр БлокировкаСеансов.Сообщение задано значением типа ФорматированнаяСтрока. Подробнее о блокировке начала сеансов см. здесь.

● Начало сеанса запрещено сервисом внешнего управления сеансов. Описание ситуации будет выводиться форматированной строкой, если сервис внешнего управления сеансами вернул параметр ErrorDescription, значение которого полученного из значения типа ФорматированнаяСтрока с помощью выражения СериализаторXDTO.XMLСтрока(). Подробнее о сервисе внешнего управления сеансами см. здесь.

Текст сообщения будет считаться форматированной строкой, если выполняется следующее выражение: Строка(СериализаторXDTO.XMLЗначение(Тип("ФорматированнаяСтрока"), Текст)) <> Текст, где Текст ‑ строка, которая передана сторонними приложениями (сервис внешнего управления сеансами, консоль кластера, утилита rac и т. д.).

Если в конфигураторе выполнить загрузку информационной базы из .dt-файла, то после завершения загрузки будет предложено выполнить перезапуск конфигуратора.

При работе в режиме 1С:Предприятие, в случае возникновения критической ошибки, система предлагает осуществить перезапуск клиентского приложения с теми же параметрами, как и у клиентского приложения, которое аварийно завершается.