При разработке мобильных приложений на платформе 1С:Предприятие часто возникает задача защитить конфигурацию от бесконтрольного копирования. Самый логичный путь для реализации «примитивной» защиты — это привязка лицензии или самой возможности запуска к уникальному идентификатору оборудования (HWID). Исторически для этих целей использовался IMEI (International Mobile Equipment Identity), однако современные реалии разработки под Android и iOS диктуют свои правила. Рассмотрим подробно, как можно решить эту задачу, какие штатные инструменты нам предоставляет 1С и с какими ограничениями мы столкнемся.
Для начала разберем, что предлагает нам встроенный язык 1С без использования сторонних инструментов. Основным объектом для получения информации об окружении является СистемнаяИнформация. В контексте нашей задачи нас интересуют два ключевых свойства. Проанализируем их работу:
Рассмотрим на примере, как получить эти данные в коде:
Инфо = Новый СистемнаяИнформация;
ИдКлиента = Инфо.ИдентификаторКлиента;
ИдУстройства = Инфо.ИдентификаторУстройства;
Сообщить("ID Клиента: " + ИдКлиента);
Сообщить("ID Устройства: " + ИдУстройства);
Проанализируем стабильность этих данных. Как показывает практика и обсуждения экспертов, ИдентификаторКлиента имеет свойство меняться при переустановке приложения. Это делает его непригодным для долгосрочной защиты, так как пользователь может просто удалить и заново поставить приложение, получив новый ID. Что касается ИдентификаторУстройства, то на ОС Android он более стабилен, а на iOS он сбрасывается, если удалить все приложения конкретного разработчика с устройства. Выясним причину такого поведения: это связано с политикой «песочницы» Apple, которая ограничивает доступ к реальным серийным номерам железа.
Многие начинающие разработчики пытаются найти способ считать именно IMEI. Мы должны четко понимать, что в современных версиях Android (начиная с 10-й версии и выше) Google полностью закрыл доступ к IMEI для обычных приложений. Даже если вы объявите разрешение READ_PHONE_STATE, система вернет пустую строку или вызовет исключение безопасности. На iOS доступ к IMEI закрыт уже очень давно.
Таким образом, использование IMEI как универсального способа идентификации в 2024 году является невозможным и нецелесообразным. Вместо этого разберем альтернативные подходы.
Для устройств на базе Android более надежным идентификатором является ANDROID_ID. Это 64-битное число, которое генерируется при первой загрузке устройства и сохраняется до тех пор, пока не будет выполнен сброс к заводским настройкам. Однако штатно 1С не предоставляет метода для его чтения.
Чтобы решить эту задачу, мы можем использовать внешние компоненты, написанные на Java (для Android). Внешняя компонента может обратиться к системному API Android напрямую:
Settings.Secure.getString(contentResolver, Settings.Secure.ANDROID_ID);
Если вы решили использовать внешнюю компоненту, алгоритм работы будет следующим:
Рассмотрим более продвинутый вариант защиты, который не ограничивается простой проверкой «зашит ли этот ID в коде». Правильнее всего реализовать схему с сервером активации. Разберем этот процесс по шагам:
Шаг 1. Сбор данных при первом запуске. При самом первом открытии приложения мы собираем максимум доступной информации:
Инфо = Новый СистемнаяИнформация;
ДанныеДляПривязки = Новый Структура;
ДанныеДляПривязки.Вставить("ИдУстройства", Инфо.ИдентификаторУстройства);
ДанныеДляПривязки.Вставить("Модель", Инфо.Модель);
ДанныеДляПривязки.Вставить("ВерсияОС", Инфо.ВерсияОС);
Шаг 2. Запрос активации. Приложение отправляет эти данные на ваш HTTP-сервис (база 1С в офисе). Сервер проверяет, есть ли свободные лицензии для этого клиента, и если всё в порядке, генерирует уникальный ТокенАктивации.
Шаг 3. Локальное хранение. Полученный токен сохраняется в мобильном приложении (например, в константе или в локальном файле). При каждом последующем запуске мы проверяем соответствие локального токена и текущего ИдентификаторУстройства.
На устройствах Apple ситуация сложнее. Единственный способ сохранить идентификатор даже после удаления приложения — использование Keychain (Связка ключей). Данные в Keychain сохраняются даже после удаления приложения. Если ваше мобильное приложение использует внешнюю компоненту, которая умеет писать в Keychain, вы можете один раз сгенерировать свой собственный GUID, записать его туда и использовать в качестве «вечного» идентификатора устройства.
Подводя итог, можно сказать, что «примитивная» защита в 1С реализуется комбинацией штатных свойств и логики на стороне сервера. Проанализируем ключевые выводы:
ИдентификаторУстройства: для большинства задач на Android его достаточно, несмотря на риск изменения при полном сбросе телефона.Реализуя подобную схему, мы создаем достаточно надежный барьер для обычного пользователя, при этом сохраняя гибкость управления доступом к нашему мобильному приложению.