При переходе на отраслевые решения 1С многие системные администраторы и программисты сталкиваются с неприятной особенностью: система лицензирования и контроля (СЛК) начинает «захватывать» лицензии для всех пользователей подряд, даже если им не требуется специфический функционал. Рассмотрим детально, как можно ограничить аппетиты СЛК и раздать лицензии только тем, кому они действительно необходимы.
Система СЛК версии 3.0 по умолчанию работает по принципу динамического распределения. Как только сеанс 1С инициирует обращение к защищенному модулю или ключу, сервер СЛК выдает лицензию из общего пула. Проблема заключается в том, что во многих «апгрейднутых» конфигурациях (например, на базе 1С:Бухгалтерия) вызов защиты прописан непосредственно в процедуре старта системы. Проанализируем ситуацию: если в коде нет проверки прав или настроек, то первые пять пользователей, зашедших в базу утром, заберут все доступные лицензии, оставив профильных специалистов без возможности работы.
Прежде чем приступать к программированию, давайте разберем стандартные возможности конфигурации. Большинство современных решений, разработанных на базе Библиотеки Стандартных Подсистем (БСП), имеют встроенные переключатели отраслевого функционала.
Пользователи или Профили групп доступа. Если там есть специфические роли, связанные с СЛК, попробуйте оставить их только целевым сотрудникам.Если штатные роли не помогают (как в случае автора темы, где удаление ролей не остановило захват лицензии), нам придется вмешаться в процесс инициализации связи с СЛК. Разберем по шагам, как это реализовать наиболее корректно с помощью расширения, не снимая основную конфигурацию с поддержки.
Выясним причину: захват происходит, потому что метод инициализации защиты вызывается в глобальном модуле или модуле управляемого приложения. Нам нужно найти этот вызов. Обычно это функции вида МенеджерЗащиты.Инициализировать() или СЛК_СвязьУстановлена().
Создадим расширение и добавим в него процедуру-перехватчик. Напишем код, который будет проверять наличие определенной роли у текущего пользователя перед выполнением стандартного кода защиты:
&Вместо("ИнициализироватьЗащиту")
Процедура Расш1_ИнициализироватьЗащиту()
// Проверяем, нужна ли лицензия этому пользователю
Если РольДоступна("НужнаОтраслеваяЛицензия") Тогда
// Вызываем стандартную инициализацию
ПродолжитьВызов();
Иначе
// Просто выходим, не запрашивая лицензию у сервера СЛК
ЗаписатьЛогСобытия("СЛК: Лицензия не запрашивалась для пользователя " + ИмяПользователя());
Возврат;
КонецЕсли;
КонецПроцедуры
Этот метод является самым надежным, так как он физически не дает компоненте СЛК отправить запрос на порт сервера (обычно 9099), если пользователь не входит в «белый список».
Рассмотрим еще один архитектурный подход. Если вы сами являетесь разработчиком или можете глубоко править код, рекомендуется перенести инициализацию СЛК из момента старта системы в момент открытия конкретных отраслевых форм или отчетов.
Вместо того чтобы захватывать лицензию ПриНачалеРаботыСистемы, проанализируем точки входа в защищенный функционал. Добавим проверку непосредственно в модуль формы:
&НаСервере
Процедура ПриСозданииНаСервере(Отказ, СтандартнаяОбработка)
Если Не ОтраслеваяЗащита.ПроверитьЛицензию() Тогда
Сообщить("Для работы с данным документом необходима отраслевая лицензия!");
Отказ = Истина;
КонецЕсли;
КонецПроцедуры
Такой подход позволяет экономить лицензии: они будут расходоваться только тогда, когда пользователь действительно открывает защищенный объект, а не просто сидит в базе, занимаясь стандартным бухгалтерским учетом.
Если программная доработка невозможна, проанализируем ситуацию с точки зрения системного администрирования. СЛК 3.0 работает через TCP/IP. По умолчанию клиентская часть 1С обращается к серверу лицензирования по порту 9099.
Мы можем настроить правила брандмауэра на сервере СЛК:
Важный нюанс: этот метод сработает только в том случае, если пользователи работают на разных физических или виртуальных машинах с разными IP. Если все работают в терминальном режиме на одном сервере, этот способ работать не будет.
Разберем типичное заблуждение, упомянутое в обсуждении. Файл nethasp.ini предназначен исключительно для управления ключами HASP (физические USB-ключи или программные лицензии самой платформы 1С). СЛК — это разработка компании «Катран Софт» (или аналогичных), и она использует собственный транспортный протокол. Попытки прописать настройки СЛК в nethasp.ini бесполезны, так как компонента защиты СЛК их просто «не видит».
Не забывайте о возможностях встроенной консоли управления СЛК (доступна через браузер по адресу http://localhost:9099). Хотя там нельзя жестко закрепить лицензию за логином 1С, вы можете:
Подведем итог: для точечного распределения лицензий СЛК 3.0 наиболее эффективным методом является использование расширений 1С. Это позволяет гибко управлять логикой захвата лицензий на основе ролей или параметров запуска, не вмешиваясь в типовую конфигурацию и не завися от сетевой инфраструктуры.