Как ограничить количество сеансов одного пользователя в 1С

Одновременная работа одного пользователя в нескольких сеансах — частая причина лишних лицензий, конфликтов данных и перегрузки сервера 1С. Сотрудник запускает базу на компьютере, терминале и удалённом рабочем столе, а сеансы «висят» в фоне, хотя реально работает человек только в одном окне. Задача администратора — ограничить число таких сеансов штатными средствами платформы или конфигурации.

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

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

Как 1С учитывает сеансы и почему их становится много

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

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

Способ 1. Настройки кластера серверов 1С

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

Полезные для задачи настройки кластера:

• Блокировка установки соединений — позволяет запретить новые подключения, например на время регламентных работ. Можно задать сообщение, которое увидит пользователь.
• Разрешение выдачи лицензий — управляет тем, какой сервер выдаёт клиентские лицензии, что влияет на учёт сеансов.
• Таймауты соединений — настройки рабочих процессов, влияющие на то, как быстро освобождаются ресурсы неактивных подключений.

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

Способ 2. Программное ограничение сеансов при входе

Самый гибкий способ — проверять число активных сеансов пользователя в момент установки соединения и отказывать во входе, если лимит превышен. Для этого используется обработчик УстановкаПараметровСеанса в модуле сеанса либо событие подключения в общем модуле, а список активных сеансов получают методом ПолучитьСеансыИнформационнойБазы().

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

Процедура УстановкаПараметровСеанса(ТребуемыеПараметры)
    МаксСеансов = 1;
    ТекущийПользователь = ИмяПользователя();
    Если ПустаяСтрока(ТекущийПользователь) Тогда
        Возврат; // служебные подключения не ограничиваем
    КонецЕсли;
    Счетчик = 0;
    Для Каждого Сеанс Из ПолучитьСеансыИнформационнойБазы() Цикл
        Если Сеанс.ИмяПользователя = ТекущийПользователь
            И Сеанс.ИмяПриложения <> "BackgroundJob" Тогда
            Счетчик = Счетчик + 1;
        КонецЕсли;
    КонецЦикла;
    Если Счетчик > МаксСеансов Тогда
        ВызватьИсключение "Превышен лимит одновременных сеансов. Завершите другой сеанс и повторите вход.";
    КонецЕсли;
КонецПроцедуры

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

Способ 3. Автоматическое завершение неактивных сеансов

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

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

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

1. 1
   Проанализируйте активные сеансы: кто и сколько держит подключений, есть ли фоновые задания от пользователей
2. 2
   Настройте автоматическое завершение неактивных сеансов, чтобы пользователи не блокировались «зависшими» подключениями
3. 3
   Добавьте программную проверку лимита сеансов при входе с исключениями для служебных учётных записей
4. 4
   Протестируйте на копии базы: вход под обычным пользователем, под администратором, запуск фоновых заданий
5. 5
   Включите механизм в рабочей базе и предупредите пользователей о новом правиле

Способ 4. Организационные и системные меры

Не всё нужно решать внутри 1С. Часть проблемы снимается на уровне инфраструктуры:

• Терминальный сервер: настройте групповые политики Windows на завершение отключённых RDP-сессий через заданное время — тогда сеансы 1С в терминале не будут висеть бесконечно.
• Ярлык запуска: уберите у пользователей возможность запускать несколько копий клиента с разными параметрами, если это не нужно по работе.
• Разделение учётных записей: выделите отдельные служебные учётные записи для обменов, интеграций и фоновых заданий, чтобы они не конкурировали за лимит с интерактивной работой.

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

Как проверить, что ограничение работает

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

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

Типичные ошибки при ограничении сеансов

Частые вопросы