Аудит расширения в облаке 1С:Фреш: от подготовки .cfe до подключения

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

Большинство отказов связано с подготовкой, а не с самой загрузкой. Расширение, которое отлично работает в локальной файловой базе, в облаке может обращаться к диску сервера, внешним ресурсам или неразделённым данным. Поэтому начинать стоит с настроек расширения в Конфигураторе.

Как подготовить расширение к проверке в 1С:Фреш

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

Свойства расширения в Конфигураторе

Откройте Конфигурация → Расширения конфигурации, выделите расширение и откройте его свойства. Проверьте:

• 🔒 Безопасный режим — включён. В безопасном режиме код не получает доступа к файлам сервера, COM-объектам и привилегированному режиму.
• 🛡️ Защита от опасных действий — включена.
• 🏷️ Префикс имён — заполнен и уникален. Все добавленные объекты, реквизиты и процедуры должны начинаться с него. Так не возникнет конфликтов имён после обновления типовой конфигурации.
• 🎯 Назначение — соответствует сути: исправление, адаптация или дополнение.
• 🔁 Режим совместимости — не выше режима совместимости основной конфигурации приложения.

Код, который в облаке не пройдёт

Перед отправкой поищите в модулях расширения (Ctrl+F с областью поиска по расширению) опасные конструкции:

• 📁 работа с файлами сервера: Новый ЗаписьТекста, КопироватьФайл, УдалитьФайлы с путями на сервере;
• 🧩 Новый COMОбъект, подключение внешних компонент без разрешения;
• 🔑 УстановитьПривилегированныйРежим(Истина) без явной необходимости;
• 🌐 HTTP-запросы к внешним адресам без запроса разрешений;
• ⚙️ Выполнить() и Вычислить() со строкой, собранной из пользовательского ввода.

Если внешний ресурс действительно нужен (например, обмен с сайтом), используйте механизм запросов разрешений на внешние ресурсы из Библиотеки стандартных подсистем. Тогда в описании для аудитора будет видно, к какому адресу и зачем идёт обращение.

Разделение данных

Типовые приложения в облаке работают с разделением данных. Расширение не должно:

1. Записывать данные в неразделённые объекты (общие для всех абонентов).
2. Читать данные других областей.
3. Менять параметры сеанса, которые отвечают за разделение.

💡 Самая простая проверка — развернуть локально копию приложения в режиме сервиса или хотя бы тестовую базу с той же версией конфигурации. Прогоните все сценарии расширения под пользователем без полных прав. Ошибки доступа вылезут ещё до аудита.

Исходный код и формат файла

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

Файл сохраняют из Конфигуратора: в окне Конфигурация → Расширения конфигурации выберите расширение и в меню Действия (или по правой кнопке) выполните сохранение в файл. Получится .cfe.

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

Доступ к сервису: кто может загружать расширения

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

Порядок такой:

1. Абонент (организация) имеет учётную запись в сервисе и подключённое приложение — например, 1С:Бухгалтерию или 1С:ЗУП в облаке.
2. Разработчик либо работает под учётной записью администратора приложения, либо администратор абонента загружает подготовленный им файл.
3. Если вы сторонний разработчик и делаете расширение для нескольких клиентов, договоритесь с поставщиком сервиса (партнёром, который обслуживает облако) о порядке проверки. У разных поставщиков условия отличаются: где-то аудит включён в тариф, где-то оплачивается отдельно.

Ситуация «разработчик снаружи, база у клиента» встречается чаще всего. Удобная схема: клиент создаёт разработчику отдельного пользователя с правами администратора, а после подключения расширения права урезают.

Загрузка файла расширения в облачное приложение

Расширение загружают не в Конфигуратор (в облаке к нему доступа нет), а прямо в пользовательском режиме приложения.

Шаги в приложении

1. Войдите в приложение под администратором.
2. Откройте Администрирование → Печатные формы, отчеты и обработки.
3. Перейдите в список Расширения.
4. Нажмите кнопку добавления из файла и выберите сохранённый .cfe.
5. Программа покажет предупреждение о том, что расширение будет проверено. Подтвердите отправку.

После этого расширение появится в списке, но работать не начнёт. Оно ждёт решения аудитора.

Что приложить к заявке

Даже если форма загрузки не требует описания, подготовьте его. Аудитору нужно понять:

• 🎯 зачем расширение (одна-две фразы);
• 📋 какие объекты типовой конфигурации оно заимствует и меняет;
• 🌐 к каким внешним ресурсам обращается, если обращается;
• 🧪 как проверить: в каком разделе кнопка, какой документ открыть.

Хорошее описание часто экономит один круг переписки.

Как проходит аудит безопасности расширения

Процедура у поставщиков сервиса похожа. Её можно разбить на этапы.

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

Что смотрят особенно внимательно

• Перехват методов типовой конфигурации. Аннотации &Вместо вызывают больше вопросов, чем &Перед и &После. Код «вместо» полностью подменяет типовую логику, и после обновления приложения он может сломаться.
• Собственные объекты метаданных. Если расширение добавляет справочники и регистры, это меняет структуру данных области. Проверяют, что объекты разделены и не конфликтуют с типовыми.
• Регламентные задания. В облаке фоновые операции идут через общую очередь заданий. Тяжёлое задание с частым запуском нагружает сервер всех абонентов.
• Запросы. Запрос без отбора по большой таблице в облаке ощущают все.

Как сократить срок проверки

Чем меньше кода, тем быстрее решение. Несколько приёмов из практики:

• ✂️ Одна задача — одно расширение. Печатная форма, доработка документа и обмен с сайтом в одном файле проверяются дольше, чем три маленьких расширения. И отказ по обмену не задержит печатную форму.
• 🧹 Чистый код перед отправкой. Удалите неиспользуемые процедуры, пустые обработчики и закомментированные блоки. Аудитор читает всё, что есть в модулях.
• 📝 Комментарии к спорным местам. Если без привилегированного режима не обойтись, прямо в коде напишите, что именно он даёт и почему пользовательских прав мало.
• 🔢 Понятная нумерация версий. Версия вида 1.0.3 в свойствах расширения сразу показывает, какую сборку смотрят.

Что означает решение проверяющего

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

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

💡 Одобрение выдают на конкретный файл. Если вы поменяли в расширении хоть строку, это новая версия, и её снова проверят.

Почему расширение не проходит аудит

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

• ❌ Конфликт с новым релизом приложения. Пока расширение ждало проверки, облако обновилось. Заимствованная форма поменялась, и расширение не применяется. Решение — проверить его на актуальном релизе и пересохранить.
• ❌ Изменение типовых объектов «на всякий случай». Заимствовано двадцать объектов, а реально меняются три. Лишние заимствования аудитор попросит убрать: они увеличивают риск конфликта при обновлении.
• ❌ Жёстко прописанные значения. Ссылки на конкретные элементы справочников по коду или наименованию одной базы. В другой области таких элементов нет, и код упадёт.
• ❌ Отладочный код. Оставленные Сообщить() в цикле, запись в журнал регистрации на каждое действие, закомментированные куски старой логики.
• ❌ Сообщения об ошибках без обработки. Расширение падает с системной ошибкой при пустом реквизите. Для облака это повод отклонить.
• ❌ Попытка обойти безопасный режим. Любой приём, который выглядит как попытка получить больше прав, гарантирует отказ.

Как исправить замечания и отправить расширение снова

Отказ — это не конец. Это список доработок.

Повторная отправка

1. Прочитайте замечания целиком. Обычно в них указаны модуль и процедура.
2. Исправьте всё за один заход. Отправка «по одному замечанию» удлиняет путь в разы.
3. Увеличьте номер версии в свойствах расширения. Так и вы, и аудитор отличите сборки.
4. Удалите из списка отклонённую версию, если это предусмотрено, и загрузите новый .cfe.
5. В описании перечислите, что исправлено: «замечание 1 — убран COM-объект, замечание 2 — добавлен отбор в запрос».

Если вы не согласны с замечанием

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

Напишите в поддержку поставщика сервиса или своему партнёру. Опишите:

• ✍️ какое замечание оспариваете;
• 🧾 почему код безопасен (с фрагментом и пояснением);
• 🔁 почему нельзя сделать иначе.

Часто компромисс находится быстро: вас попросят сузить участок кода или вынести логику в отдельную процедуру.

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