Почему при первом запуске 1С авторизация проходит только с десятой попытки и как это исправить

← На главную

Нередко после обновления платформы 1С:Предприятие 8.3 системные администраторы и разработчики сталкиваются с аномальным поведением системы при входе пользователей. Типичная картина выглядит так: утром при старте рабочего дня ни один обычный пользователь не может войти в клиент-серверную базу, получая ошибку проверки логина и пароля. Однако после 10–15 упорных попыток вход неожиданно удается, либо система начинает беспрепятственно пускать всех пользователей сразу после того, как в базу хотя бы один раз зайдет пользователь с административными правами. Проанализируем, почему возникает такое поведение и как его исправить.

Причины сбоя: механизм разделения данных и кэш рабочих процессов

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

Строгая привязка пользователя к значению разделителя. Если в свойствах общего реквизита включено использование разделителя, а в карточке пользователя задано фиксированное значение (например, конкретный элемент справочника отделов), платформа выполняет сопоставление учетной записи с конкретной областью данных.
Включение разделения аутентификации. Если для общего реквизита свойство Разделение аутентификации установлено в значение Разделять, платформа допускает существование одинаковых имен пользователей в разных независимых областях. В этом случае при обычной авторизации без предварительно переданного контекста сервер не может определить, в какой именно области искать пользователя.
Холодный старт рабочих процессов кластера (rphost). В ряде релизов платформы (в частности, ветки 8.3.9) переработана подсистема кэширования метаданных и внутренних таблиц учетных записей. После ночного простоя, перезагрузки службы сервера или планового перезапуска рабочих процессов внутренний кэш разделителей в памяти rphost пуст. Первые запросы обычных пользователей завершаются ошибкой авторизации.
Прогрев кэша администратором. Пользователь с полными административными правами, как правило, не имеет жесткой привязки к разделителям и входит в общую (неразделенную) область. При его успешной авторизации рабочий процесс инициализирует структуры данных информационной базы и прогревает кэш. После этого все остальные пользователи получают возможность беспрепятственно войти в систему.

Способ 1. Отключение разделения аутентификации в конфигураторе

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

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

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

Способ 2. Явное указание области данных в параметрах запуска

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

В окне запуска 1С выберем целевую базу и нажмем кнопку Изменить.
Перейдем на страницу настройки параметров запуска приложения.
В поле Дополнительные параметры запуска добавим параметр /Z с указанием значения разделителя: /Z "+000000001" где вместо 000000001 указывается код или идентификатор соответствующего отдела.

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

Способ 3. Инициализация параметров сеанса в модуле сеанса

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


Процедура УстановкаПараметровСеанса(ТребуемыеПараметры)
    
    // Принудительно инициализируем контекст текущего пользователя
    Если ТребуемыеПараметры = Неопределено Или ТребуемыеПараметры.Найти("ТекущийПользователь") <> Неопределено Тогда
        ПараметрыСеанса.ТекущийПользователь = УправлениеПользователями.ПолучитьТекущегоПользователя();
    КонецЕсли;

КонецПроцедуры

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

Способ 4. Настройка автоматического регламентного прогрева базы

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

Создадим в базе специального служебного пользователя без привязки к разделителям данных с ролью, позволяющей вход в систему.
На сервере в планировщике задач Windows создадим задание, запускающее 1С за 15–20 минут до прихода пользователей с помощью командного файла:
```
"C:\Program Files\1cv8\8.3.9.1818\bin\1cv8c.exe" ENTERPRISE /S "Server1C\BaseName" /N "ServiceAdmin" /P "ComplexPassword" /C "AutoWarmUp"
```
В модуле управляемого приложения в процедуре ПриНачалеРаботыСистемы добавим проверку параметра запуска для автоматического закрытия прогревочной сессии:
```
Если ПараметрЗапуска = "AutoWarmUp" Тогда
    ЗавершитьРаботуСистемы(Ложь);
КонецЕсли;
```

Такой сценарий обеспечивает заблаговременный запуск и прогрев процессов rphost, после чего обычные учетные записи авторизуются с первого раза.

Способ 5. Смена проблемного релиза платформы

Если ошибки аутентификации сопровождаются сбоями в работе пула соединений SQL Server (например, потерей временных таблиц #tt1, сбоями транзакций в Microsoft SQL Server Native Client или ошибками кэша метаданных), наиболее надежным решением остается откат на стабильную версию платформы. Для конфигураций, использовавших релизы 8.3.7, рекомендуется выполнить возврат на проверенную сборку 8.3.7.2027 либо запланировать переход на более поздние протестированные релизы платформы, где исправлены ошибки механизма разделения аутентификации.