Как получить идентификатор пользователя ИБ в 1С: Предприятие

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

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

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

Просмотр списка подключенных пользователей через интерфейс

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

Однако, если ваша цель — увидеть именно активные сеансы в реальном времени, необходимо воспользоваться меню «Сервис» → «Монитор пользователей» (в старых версиях) или «Администрирование» → «Активные пользователи». В открывшемся окне отображается таблица, где каждому сеансу соответствует уникальный номер. Этот номер часто и выступает в роли временного идентификатора сессии.

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

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

⚠️ Внимание: Список активных пользователей обновляется не мгновенно. Задержка может составлять от нескольких секунд до минуты в зависимости от нагрузки на сервер. Не принимайте решения о завершении сеанса, основываясь только на данных, полученных секунду назад.

Использование консоли запросов для получения GUID

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

Основная таблица, содержащая информацию о сеансах, называется СеансыИнформационнойБазы. Чтобы получить список всех активных подключений с их уникальными идентификаторами, выполните следующий запрос. Он вернет таблицу с полями: УникальныйИдентификатор, Пользователь, НачальноеВремя и Приложение.

ВЫБРАТЬ
СеансыИнформационнойБазы.УникальныйИдентификатор КАК Идентификатор,
СеансыИнформационнойБазы.Пользователь КАК ИмяПользователя,
СеансыИнформационнойБазы.НачальноеВремя
ИЗ
РегистрСведений.СеансыИнформационнойБазы КАК СеансыИнформационнойБазы

Результатом выполнения запроса будет список, где в колонке «Идентификатор» отобразится строка вида cf8644c7-46d2-48e3-9c21-252324242424. Это и есть тот самый уникальный идентификатор, который система присваивает каждому новому входу. Он необходим, например, для принудительного завершения сеанса через внешние скрипты или для анализа журнала регистрации.

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

Программное получение идентификатора в коде 1С

Разработчикам конфигураций часто требуется получить идентификатор текущего пользователя непосредственно в коде обработки или документа. Для этого в платформе 1С:Предприятие предусмотрен специальный объект глобального контекста. Использование этого метода гарантирует, что вы получите данные именно о том сеансе, в котором выполняется код.

Основной метод для получения уникального идентификатора текущего сеанса — это свойство УникальныйИдентификаторСеанса объекта СеансИнформационнойБазы. Этот метод возвращает значение типа УникальныйИдентификатор, которое можно преобразовать в строку для записи в регистры или лог-файлы. Пример кода представлен ниже.

Функция ПолучитьМойИдентификатор()

Возврат СеансИнформационнойБазы.УникальныйИдентификаторСеанса;

КонецФункции

Также может возникнуть задача получить идентификатор конкретного пользователя по его имени. Для этого используется объект ПользователиИнформационнойБазы. Вы можете найти пользователя по имени и получить его внутренний UUID, который не меняется при переименовании учетной записи. Это особенно полезно при миграции данных между базами.

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

Анализ журнала регистрации для ретроспективного поиска

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

Для работы с журналом перейдите в режим «Предприятие» с правами администратора и выберите «Администрирование» → «Журнал регистрации». В настройках отбора обязательно укажите нужный период времени. Без ограничения периода поиск может занять значительное время из-за большого объема данных.

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

Тип события	Описание	Где искать ID
ВходВПрограмму	Фиксация успешного входа пользователя	Реквизит «Сеанс»
ВыходИзПрограммы	Корректное завершение работы	Реквизит «Сеанс»
БлокировкаДанных	Возникновение блокировки записи	Реквизит «СеансБлокировщик»
ИзменениеНастроек	Смена параметров системы	Реквизит «Пользователь»

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

⚠️ Внимание: Объем журнала регистрации может достигать десятков гигабайт. Перед выполнением сложных выборок убедитесь, что на диске достаточно свободного места, иначе работа базы данных может быть приостановлена.

Особенности работы в файловом и клиент-серверном режиме

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

В клиент-серверном варианте (с использованием сервера 1С:Предприятия и СУБД) управление сеансами централизовано. Сервер хранит таблицу активных подключений в оперативной памяти и в системных таблицах базы данных (например, в PostgreSQL или MS SQL Server). Это позволяет получать информацию о пользователях даже в том случае, если сам клиент 1С не запущен, обращаясь напрямую к серверу.

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

Если вы администрируете кластер серверов 1С, вы можете использовать консоль управления кластером (mmc snap-in). Там в дереве объектов можно раскрыть узел «Сеансы» и увидеть подробную информацию по каждому подключению, включая PID процесса на сервере и уникальный ID сеанса. Это наиболее мощный инструмент для диагностики проблем производительности.

Влияние версии платформы на идентификаторы

В версиях платформы 1С ниже 8.3.10 структура некоторых системных таблиц отличалась. Если вы используете очень старую версию (например, 8.2), запросы к регистру сведений «СеансыИнформационнойБазы» могут не работать. В таких случаях используйте только консоль управления кластером или внешние утилиты.

Частые ошибки и способы их решения

При попытке получить идентификатор пользователя новички часто сталкиваются с рядом типовых ошибок. Одна из самых распространенных — путаница между именем пользователя в операционной системе (Windows Login) и именем пользователя в базе 1С. Эти данные могут совпадать, но часто бывают разными, особенно при использовании доменной авторизации.

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

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

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

В чем разница между Именем пользователя и УникальнымИдентификатором?

Имя пользователя — это читаемая строка (например, "ИвановИИ"), которую можно изменить в настройках прав доступа. УникальныйИдентификатор (GUID) — это технический код, который присваивается пользователю один раз при создании и не меняется никогда, даже при переименовании. Для программирования и интеграции всегда надежнее использовать GUID.

Можно ли получить идентификатор пользователя, если база закрыта для всех?

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

Как найти владельца заблокированной записи по идентификатору?

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

Где хранится история идентификаторов после перезагрузки сервера?

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

Влияет ли обновленная платформа 1С на формат идентификаторов?

Формат GUID (16 байт, отображаемых как 32 шестнадцатеричные цифры с дефисами) остается неизменным на протяжении многих версий платформы 1С. Однако методы доступа к этой информации (свойства объектов, имена системных таблиц) могут меняться. Всегда сверяйтесь с синтаксическим помощником вашей конкретной версии платформы.