При разработке мобильных решений на платформе «1С:Предприятие» разработчики часто сталкиваются с тем, что привычные механизмы авторизации, работающие в «толстом» или «тонком» клиенте, здесь ведут себя иначе. Вопрос идентификации пользователя в мобильном приложении является критически важным для обеспечения безопасности данных и разделения прав доступа. В этой статье мы подробно разберем, как обойти системные ограничения мобильной платформы и реализовать надежную систему входа.
Для начала проанализируем, почему стандартный подход с созданием списка пользователей в Конфигураторе не подходит для мобильного приложения. Согласно документации ИТС, мобильная платформа имеет ряд существенных архитектурных особенностей:
Важно различать Мобильную платформу (автономное приложение) и Мобильный клиент. В мобильном клиенте, который является по сути «окном» в серверную базу, доступны все стандартные средства аутентификации 1С. Мы же сосредоточимся на мобильной платформе, где требуется создание прикладной (собственной) системы авторизации.
Рассмотрим по шагам самый распространенный способ идентификации, который рекомендуют опытные разработчики. Суть метода заключается в создании «прослойки» между интерфейсом и системным входом.
Во-первых, создадим в метаданных справочник Пользователи. В нем мы будем хранить список лиц, которым разрешен доступ к приложению. Для безопасности не рекомендуется хранить пароли в открытом виде — лучше использовать хэш-суммы.
Во-вторых, создадим Константу.ТекущийПользователь (тип ссылки на наш справочник) или используем параметры сеанса. При запуске приложения проанализируем, установлен ли текущий пользователь.
Разберем пример кода в модуле управляемого приложения:
Процедура ПриНачалеРаботыСистемы()
// Проверяем, авторизован ли пользователь
ТекущийПользователь = ПолучитьТекущегоПользователя();
Если ТекущийПользователь.Пустая() Тогда
// Открываем форму авторизации
ПараметрыФормы = Новый Структура;
ОткрытьФорму("Справочник.Пользователи.Форма.ФормаАвторизации", ПараметрыФормы, , Истина);
КонецЕсли;
КонецПроцедуры
В самой форме авторизации мы реализуем поля ввода логина и пароля. При нажатии кнопки «Войти» приложение должно проверить соответствие данных. Если проверка проходит успешно, идентификатор пользователя записывается в локальную память устройства, и пользователю открывается основной интерфейс.
Современные версии платформы (начиная с 8.3.10) предоставляют отличный инструмент для повышения удобства — работу со сканерами отпечатков пальцев и распознаванием лиц. Проанализируем возможности менеджера СредстваБиометрическойАутентификации. Это позволяет пользователю не вводить пароль каждый раз на маленьком экране смартфона.
Посмотрим на пример реализации проверки биометрии:
&НаКлиенте
Процедура ПроверитьБиометрию()
Если СредстваБиометрическойАутентификации.ПоддерживаетсяБиометрическаяАутентификация() Тогда
Описание = "Подтвердите личность для входа в систему";
СредстваБиометрическойАутентификации.НачатьАутентификацию(Новый ОписаниеОповещения("ЗавершитьАутентификацию", ЭтотОбъект), Описание);
КонецЕсли;
КонецПроцедуры
&НаКлиенте
Процедура ЗавершитьАутентификацию(Результат, ДополнительныеПараметры) Экспорт
Если Результат Тогда
Сообщить("Доступ разрешен!");
// Здесь код открытия главного экрана
Иначе
Сообщить("Ошибка идентификации");
КонецЕсли;
КонецПроцедуры
Выясним, как упростить жизнь пользователю и привязать конкретный аппарат к учетной записи в центральной базе. У каждого мобильного устройства есть свой ИдентификаторКлиента. Мы можем получить его через объект СистемнаяИнформация.
Сценарий работы может быть следующим: при первом запуске пользователь вводит логин и пароль, приложение отправляет эти данные вместе с ID устройства на сервер. Сервер создает связку «Пользователь — ID устройства». При последующих запусках приложение просто передает свой идентификатор, и сервер автоматически понимает, кто обращается за данными. Это исключает необходимость повторного ввода пароля до тех пор, пока администратор не сбросит привязку на стороне сервера.
Поскольку в мобильной платформе системный пользователь один, возникает риск: если кто-то получит доступ к файловой системе телефона, он сможет скопировать базу данных. Чтобы этого избежать, проанализируем механизм пароля данных.
С помощью метода УстановитьПарольДанных() мы можем зашифровать всю локальную базу. Это критически важно, если в приложении хранится коммерческая информация или персональные данные. При установленном пароле данных платформа потребует его еще до загрузки интерфейса 1С. Без этого пароля файл базы данных (1Cv8.1cd) будет представлять собой набор зашифрованных байтов, бесполезных для злоумышленника.
Рассмотрим более продвинутый вариант, который используется в крупных корпоративных мобильных решениях. Вместо прямой передачи пароля при каждом обмене данными, проанализируем использование токенов доступа (по аналогии с JWT).
Алгоритм работы следующий:
Этот подход позволяет не хранить пароль пользователя в памяти мобильного устройства и дает возможность мгновенно отозвать доступ у конкретного гаджета, просто аннулировав токен на сервере.
Подводя итог, можно сказать, что хотя штатная система пользователей 1С в мобильной платформе ограничена, она предоставляет достаточно инструментов для создания собственного безопасного механизма идентификации. Разберем основные правила хорошего тона при реализации:
ХешированиеДанных.ИдентификаторКлиента для контроля количества подключенных устройств.Применяя эти подходы, вы сможете создать защищенное и удобное мобильное приложение, которое корректно идентифицирует каждого сотрудника и ограничивает доступ к конфиденциальной информации.