Sign 26.450.0–26.600.0: IDOR в AccessCheck, установщик на миграциях и папки в сейфе компании

Версии 26.450.0, 26.500.0 и 26.600.0 модуля sign («Подписание документов») вышли в коробочный Битрикс24 одним днём, 11 сентября 2026 года, так указано в официальном канале «Битрикс24 changelog». Срочнее всего 26.500.0, которая закрывает IDOR в фильтре AccessCheck и заодно переводит установщик на миграции, а 26.600.0 и 26.450.0 добавляют папки в сейфе компании, закрепление и чаты групп подписантов и облегчённый Госключ. Читать администраторам коробки, где сотрудники подписывают документы, и разработчикам, которые вызывают контроллеры и операции sign из своего кода или забирают сейф через REST.

Ставьте 26.500.0 ради AccessCheck

Bitrix\Sign\Engine\ActionFilter\AccessCheck проверяет права перед действиями контроллеров sign. Если правило объявлено с itemType, право проверяется на конкретный объект, и ID этого объекта фильтр берёт из запроса. До 26.500.0 он искал ID только в JSON-теле. Одиночное правило без ID в JSON отклоняло запрос, а условие внутри LogicOr или LogicAnd сводилось к проверке общего права без привязки к объекту. Так объявлено большинство проверок в Controllers\V1\Document и контроллерах Controllers\V1\Document\*.

Теперь фильтр ищет ID во всех источниках параметров контроллера, и ключ должен найтись ровно в одном. Если ID нет или он пришёл сразу в нескольких местах, например в GET и в теле, запрос отклоняется. Комментарии к правке ссылаются на внутренние тикеты: jabber #249372 («fail-closed against IDOR») и jabber #249595 про подмену источника параметра.

В том же релизе поправили и другие проверки доступа:

• Access\Rule\BaseRule::isCrmEntityTypeMismatch() отказывает, если CRM-право относится к другому типу сущности, чем элемент. Право на шаблон для обычного, не шаблонного документа тоже даёт отказ.
• Operation\CheckDocumentAccess возвращает ошибку доступа, если право CRM запрошено для документа с другим entityTypeId.
• Document::modifyIntegrationIdAction и GroupChat::createDocumentChatAction проверяют доступ к конкретному документу по uid или documentId, раньше они смотрели только на общее право. Новый createDocumentChatByEntityAction проверяет документ через checkByItem() сам.

Скрипт или фронтенд, который кладёт ID документа и в строку запроса, и в тело, после обновления получит 401. Сменился и текст отказа. AccessCheck и Controllers\V1\B2e\Signers вместо MAIN_ENGINE_FILTER_AUTHENTICATION_ERROR отдают свои фразы SIGN_ENGINE_ACTION_FILTER_ACCESS_CHECK_ERROR_ACCESS_DENIED и SIGN_CONTROLLERS_V1_B2E_SIGNERS_ERROR_ACCESS_DENIED. Если ваш код узнавал отказ по тексту, переключите его на статус ответа.

В 26.600.0 серверную проверку получили и группы подписантов. Интерфейс и раньше не показывал уволенных и экстранет-пользователей, а теперь SignerEligibilityService не даёт добавить их прямым запросом к Controllers\V1\B2e\Signers. Если в развёрнутом списке есть уволенный (ACTIVE = 'N'), экстранет-пользователь или несуществующий ID, отклоняется весь запрос с ошибкой SIGN_CONTROLLERS_V1_B2E_SIGNERS_ERROR_INELIGIBLE_USERS. Код, который сам наполняет группы, должен отсеивать таких пользователей до отправки, иначе в группу не попадёт никто.

Проверьте свой код до обновления

В 26.450.0 публичные сигнатуры не менялись, поломки пришли с 26.500.0 и 26.600.0.

Не рассчитывайте на InstallEvents() у модуля sign

В 26.500.0 установщик sign переехал на миграции ядра. Файлы install/db/mysql/install.sql, uninstall.sql и такие же для pgsql удалены. installDB() и uninstallDB() теперь вызывают унаследованные от CModule методы installMigrations() и uninstallMigrations($dropTables). Первый подключает install/migrations/tables.php, events.php и agents.php, второй events.php и, если данные удаляются, tables.php.

Из класса sign в install/index.php удалили публичное свойство $eventsData и методы InstallEvents(), UnInstallEvents() и installAgents(). Вызов installAgents() закончится фаталом, а вот InstallEvents() и UnInstallEvents() молча уйдут в пустые методы базового CModule. Скрипт, который чинил обработчики sign через CModule::CreateModuleObject('sign')->InstallEvents(), после обновления отработает без ошибок и ничего не зарегистрирует. Обработчики теперь описаны в install/migrations/events.php.

Из uninstallDB() убрали \CAgent::removeModuleAgents(). Агенты модуля при удалении по-прежнему снимает ModuleManager::unRegisterModule().

Уберите isEntityId из запросов на чат документа

Controllers\V1\Integration\Im\GroupChat::createDocumentChatAction в 26.500.0 принимает (int $chatType, int $documentId, DocumentRepository $documentRepository). Параметр bool $isEntityId = false удалён, а DocumentRepository подставляется автовайрингом, для этого его зарегистрировали в .settings.php модуля по имени класса. Документ по ID сущности CRM теперь ищет отдельное действие createDocumentChatByEntityAction(int $chatType, int $entityId, DocumentRepository $documentRepository).

В JS-API то же самое. У createDocumentChat(chatType, documentId) больше нет третьего аргумента, для поиска по сущности появился createDocumentChatByEntity(chatType, entityId). Старый вызов с isEntityId передаст ID сущности CRM туда, где ждут ID документа sign, и получит ошибку или создаст чат другого документа.

Передавайте аргументы операций шаблонов по имени

В конструктор Operation\Document\Template\Send в 26.500.0 добавили ?string $externalId и ?string $externalDate, причём перед необязательными ?DocumentService, ?ProfileProvider и ?MemberDynamicFieldInfoProvider. Позиционный вызов, который передавал DocumentService, теперь отдаст его в $externalId и упадёт с TypeError. Именованным аргументам такой сдвиг не страшен.

В примере документ по шаблону отправляет сотрудник. Рег. номер и дату Send проверяет только в таких документах, и для них обязателен sendFromUserId.

        <?php declare(strict_types=1);

use Bitrix\Main\Loader;
use Bitrix\Main\Result;
use Bitrix\Sign\Item\Document\Template;
use Bitrix\Sign\Operation\Document\Template\Send;
use Bitrix\Sign\Service\Container;

function sendEmployeeDocument(
    Template $template,
    int $responsibleUserId,
    int $employeeUserId,
    string $registrationNumber,
): Result {
    Loader::requireModule('sign');

    $result = (new Send(
        template: $template,
        responsibleUserId: $responsibleUserId,
        sendFromUserId: $employeeUserId,
        externalId: $registrationNumber,
        documentService: Container::instance()->getDocumentService(),
    ))->launch();

    foreach ($result->getErrors() as $error) {
        if ($error->getCode() === Send::ERROR_CODE_EXTERNAL_ID_REQUIRED) {
            // в бланке есть место под рег. номер, а номер пустой
        }
    }

    return $result;
}

    

У Operation\Document\Template\FixDismissalPresetTemplate::__construct удалён второй параметр bool $isOptionsReloaded, а у InstallPresetTemplatesResult больше нет конструктора и свойства isOptionsReloaded. Если вы передавали этот флаг или читали его из результата, уберите оба места.

Добавьте AliasContext в свои стратегии алиасов

У Service\Placeholder\FieldAlias\Strategy\PreloadableStrategyInterface в 26.600.0 поменялась сигнатура метода:

        public function preloadForFieldNames(array $fieldNames, ?AliasContext $context = null): void;

    

Класс, который реализует интерфейс со старой сигнатурой, не загрузится, PHP остановится с фаталом о несовместимом объявлении метода. HcmLinkFieldStrategy и StrategyRegistry в самом модуле уже обновлены.

Проверьте шаблоны до увольнения сотрудника

Integration\Main\SignersListEventHandler с 26.600.0 делает при деактивации и удалении пользователя больше, чем раньше. Как и прежде, он убирает пользователя из всех групп подписантов. Дополнительно ставится фоновая задача (addBackgroundJob), которая вызывает TemplateService::markTemplatesWithUserAsIncomplete(). Шаблоны, где участвует этот пользователь, переходят в Status::NEW и Visibility::INVISIBLE, у документов сбрасывается представитель (DocumentRepository::resetRepresentativeByIds()), видимость папок шаблонов пересчитывается.

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

Ещё две правки в том же обработчике. OnAfterUserUpdate теперь срабатывает, только если $data['RESULT'] непустой, то есть обновление прошло. При удалении пользователя стираются и его личные настройки групп (deleteAllUserOptions()), например закрепления.

Сверьте выдачу sign.b2e.mysafe.tail

REST-метод sign.b2e.mysafe.tail (Rest\B2e\MySafe) в 26.600.0 собирает выборку по-новому. При включённой опции SAFE_FOLDER_GROUPING_ALLOWED (по умолчанию Y) фильтр строится через ListService::buildFlatDocumentFilter(), и в выборку входят документы из папок сейфа, доступных пользователю на чтение. Каждая строка получает поле folderName. С выключенной опцией работает buildOwnerScopeFilter(). Прежний приватный preparePermissionFilterForMySafe() удалён, а member_id теперь вычисляется с учётом документа.

Если интеграция выгружает сейф в кадровую или учётную систему, прогоните метод на тестовом портале до и после обновления и сравните состав строк и member_id. Папки выключаются опцией, и тогда метод переходит на buildOwnerScopeFilter():

        <?php declare(strict_types=1);

use Bitrix\Main\Config\Option;
use Bitrix\Main\Loader;
use Bitrix\Sign\Config\Feature;

Loader::requireModule('sign');

if (Feature::instance()->isSafeFolderGroupingAllowed()) {
    Option::set('sign', 'SAFE_FOLDER_GROUPING_ALLOWED', 'N');
}

    

Включите журнал ошибок sign заново

Service\Container::getLogger() с 26.500.0 иначе выбирает запасной логгер. Если логгер sign.<channel> не описан в секции loggers, модуля bitrix24 нет, а опция log_<channel>_level пустая, модуль получает NullLogger. Раньше в той же ситуации работал Message2LogLogger с уровнем ERROR и писал через AddMessage2Log. В коробке модуля bitrix24 нет, поэтому после обновления ошибки sign по умолчанию никуда не пишутся.

Вернуть журнал можно двумя способами: описать логгер sign.<channel> в секции loggers в .settings.php или задать уровень в опции модуля, например Option::set('sign', 'log_<channel>_level', 'error'). Имена каналов ищите в вызовах getLogger() в bitrix/modules/sign/lib.

Новое

Различайте два Госключа

26.450.0 добавляет провайдер подписи ProviderCode::GOS_KEY_LITE = 'GOS_KEY_LITE' со строковым представлением goskey-lite. Его понимают createFromProviderLikeString(), toRepresentativeString(), toAnalyticString() (метка integration_Goskluch_Light) и getProviderName(). ProviderCode::getAll() тоже его возвращает, поэтому goskey-lite попадает в supportedProviders, которые Operation\GetRegisteredCompanies передаёт сервису подписи. Судя по языковому файлу, облегчённая версия подключает компанию к Госключу без получения API-ключа. Срок ключа у неё не истекает, #isProviderExpired() в provider-selector.js для goskey-lite всегда возвращает false.

В интерфейсе оба провайдера называются «Госключ», в английской локали оба «GK». Код, который перебирает getAll() или разбирает провайдер через match без default, после обновления встретит новое значение, а отчёт на getProviderName() покажет два одинаковых «Госключа». Подпись для отчёта можно собрать так (модуль sign к этому моменту должен быть подключён):

        <?php declare(strict_types=1);

namespace Vendor\Hr\Report;

use Bitrix\Sign\Type\ProviderCode;

final class ProviderLabel
{
    public static function get(string $provider): string
    {
        // понимает и 'GOS_KEY_LITE', и 'goskey-lite'
        $code = ProviderCode::createFromProviderLikeString($provider);

        return match ($code) {
            null => 'Неизвестный провайдер',
            ProviderCode::GOS_KEY_LITE => 'Госключ без API-ключа',
            default => ProviderCode::getProviderName(ProviderCode::toRepresentativeString($code)),
        };
    }
}

    

С 26.600.0 у Item\Company есть флаг $goskeyLiteAvailable. Значение приходит от сервиса в поле goskey_lite_available (Controllers\V1\Integration\Crm\B2eCompany), его учитывает JS-функция isGoskeyLitePromoAllowed(), которая решает, показывать ли тур sign-b2e-goskey-lite-promo. В 26.700.0 у облегчённого Госключа появилось ограничение по тарифу, в коробке без модуля bitrix24 оно не действует (разбор sign 26.700.0).

Разложите сейф компании по папкам

Сначала, в 26.500.0, сейф компании (sign.document.list с type=safe) научился сортировать документы по названию и дате подписания. Поля сортировки описывает enum Type\MySafeSortField (DOCUMENT.TITLE, DATE_SIGN), а MemberRepository::listB2eMembersWithResultFilesForMySafe() получил параметры ?MySafeSortField $orderField = null и Main\DB\Order $orderDirection = Main\DB\Order::Desc. Документы без даты подписания уходят в конец при любом направлении, для этого есть runtime-поле DATE_SIGN_EMPTY.

В 26.600.0 в том же гриде появились папки. Ими управляет контроллер Controllers\V1\B2e\Document\SafeFolder с действиями create, rename, delete, listByDepthLevel, listPeople и moveDocuments, последнее переносит не больше 1000 документов за раз. Права описаны действиями ACTION_B2E_MY_SAFE_FOLDER_READ, ACTION_B2E_MY_SAFE_FOLDER_CREATE, ACTION_B2E_MY_SAFE_FOLDER_WRITE и ACTION_B2E_MY_SAFE_FOLDER_DELETE, правилом Access\Rule\SafeFolderRule и типом AccessibleItemType::SAFE_FOLDER в переписанном AccessCheck. AccessInstaller::installMissingSafeFolderPermissions() добавляет права на папки ролям по умолчанию (сотруднику SELF, руководителю SUBDEPARTMENT) и не трогает уже заданные значения, вызывает его ReinstallAccessPermissionsAgent::run().

Разовый агент Agent\UpdateDocumentSafeFolderRelationAgent::run(int $lastId = 0) кладёт все записи сейфа в корень «Без папки» пачками по 1000. Имя класса оставили прежним ради стабильной регистрации агента, хотя переносит он теперь записи участников. В комментарии к агенту сказано, что папка привязана к участнику. Всю функцию выключает опция SAFE_FOLDER_GROUPING_ALLOWED модуля sign.

Закрепляйте группы подписантов и выгружайте их в Excel

С 26.500.0 группу подписантов можно выгрузить в Excel. Выгрузку делает Service\Sign\SignersList\ExcelExportService по шаблону sign.b2e.signers.edit/templates/excel/template.php, лимит 10 000 строк (MAX_SIGNERS_EXPORT), и есть параметр запроса exportSelectedIds.

26.600.0 добавляет к группам ещё несколько возможностей:

• закрепление: действия Signers::pinListAction и unpinListAction, методы SignersListService::pinList(), unpinList() и listPinnedListIds(), а личные настройки хранит новая таблица SignersListUserOptionTable с кодом Type\SignersList\UserOptionCode::Pinned;
• сортировку по Type\SignersList\SortField (TITLE, DATE_MODIFY, ID), под неё и под закреплённые группы SignersListService::listWithFilter() получил необязательные ?SortField $sortField, Order $sortDirection и ?int $pinnedForUserId;
• групповой чат по группе через GroupChat::createSignersListChatAction (POST и CSRF) и операцию Operation\Signers\CreateGroupChat;
• получателей поста в ленте через Signers::getFeedRecipientsAction и Service\Integration\Socialnetwork\FeedPostService.

При удалении группы SignersListTable::onAfterDelete() чистит связанные с ней личные настройки.

Номер и дата в документах, которые создаёт сотрудник

Документ, который сотрудник отправляет по шаблону, с 26.500.0 может нести регистрационный номер и дату создания. Controllers\V1\B2e\Document\Template::sendAction() принимает ?string $externalId и ?string $externalDate, а getFieldsAction возвращает флаги hasRegistrationNumberPlaceholder и hasCreationDatePlaceholder. Коды региональных блоков бланка отдаёт BlockRepository::getExistingB2eRegionalBlockCodesByBlankId(). Если поле обязательно и не заполнено или дата кривая, Send вернёт ошибку с кодом Send::ERROR_CODE_EXTERNAL_ID_REQUIRED, ERROR_CODE_EXTERNAL_DATE_REQUIRED или ERROR_CODE_EXTERNAL_DATE_INVALID.

В Config\Const\OnboardingTemplate появился комментарий-предупреждение. Пресет онбординга должен оставаться с initiatedByType 'company' и без региональных блоков, иначе новая проверка обязательных полей в Send заблокирует пользователя. Со своими шаблонами для сотрудников так же. Если в бланке есть региональный блок, сотрудник не отправит документ, пока не заполнит соответствующее поле.

HR-бот отмечает, что компания получила документ

Отметки о получении документа компанией пришли в 26.600.0. Сценарии описывает Type\B2e\ReceiptScenario (CompanyInitiated и EmployeeInitiated), получателя отметки определяет Service\B2e\ReceiptRecipientResolver. HR-бот получил сообщения Messages\ByEmployee\ReceivedByCompany и Messages\ByCompany\ReceivedSignedByCompany, а HrBotMessageService методы sendInviteMessageExpectingCompanyReceipt(), handleCompanyReceivedByEmployeeDocument() и handleCompanyReceivedSignedByCompanyDocument(). Логика лежит в lib/Callback/Handler.php и lib/Operation/Member/ResultFile/Save.php.

В ResultFile/Save.php есть защита от гонки. Отметку не отправляют, если документ уже остановлен, а агент повторной загрузки всё ещё сохраняет файл результата.

БД и агенты

С 26.500.0 схема sign описана в install/migrations/tables.php через построитель Bitrix\Main\UpdateSystem\Migration. Таблиц по-прежнему 22, с b_sign_blank по b_sign_signers_list_user, и список имён совпадает со старым install.sql. Колонки построчно мы не сверяли. Рядом лёг migration_config.json с defaultTableName: b_sign_blank и сопоставлением каталогов install/activities, components и js. Шестнадцать регистраций обработчиков для crm, bitrix24, main, pull, intranet, rest и im переехали в events.php, агенты в agents.php.

В agents.php подробно расписано, почему два агента регистрируются через \CAgent::AddAgent с next_exec, а не хелпером миграций. ConvertProviderSchemesAgent стартует через 3600 секунд, ReinstallAccessPermissionsAgent через 960, чтобы CRM успела создать роли. Там же упомянуты апдейтеры 23.600.0, 23.600.100 и 24.800.0. Разовый агент DocumentPlaceholderCacheEventHandler::invalidateDocumentPlaceholderListCacheAgent() сбрасывает кеш плейсхолдеров после обновления.

В 26.600.0 схема меняется уже только в tables.php. Там появились:

• b_sign_document_folder (ID, TITLE, CREATED_BY_ID, DATE_CREATE, VISIBILITY, STATUS, MODIFIED_BY_ID, DATE_MODIFY, индекс по CREATED_BY_ID);
• b_sign_document_folder_relation (ENTITY_ID bigint, ENTITY_TYPE varchar(50), PARENT_ID, DEPTH_LEVEL, CREATED_BY_ID и уникальный индекс UX_B_SIGN_DOC_FOLDER_REL_ENTITY по ENTITY_ID и ENTITY_TYPE);
• b_sign_signers_list_user_option (первичный ключ LIST_ID, USER_ID, OPTION_CODE и поле DATE_CREATE);
• индексы IX_B_SIGN_DOCUMENT_REPRESENTATIVE_ID на b_sign_document и IX_B_SIGN_MEMBER_ENTITY_ROLE (ENTITY_ID, ENTITY_TYPE, ROLE) на b_sign_member.

Как эти изменения доезжают до уже установленных порталов, из диффа не видно. После обновления проверьте, что таблицы на месте:

        <?php declare(strict_types=1);

use Bitrix\Main\Application;

$connection = Application::getConnection();
foreach (['b_sign_document_folder', 'b_sign_document_folder_relation', 'b_sign_signers_list_user_option'] as $table) {
    echo $table, ': ', $connection->isTableExists($table) ? 'есть' : 'НЕТ', PHP_EOL;
}

    

Мелочи и находки

• Все три версии собраны в июле (VERSION_DATE 9, 10 и 23 июля) и по дате сборки старше предыдущего хотфикса 26.400.100 от 24 июля. Его правка в DocumentService::cloneDiskFile сохранилась во всех трёх.
• Выгрузка участников документа в Excel из sign.document.list раньше шла без лимита (limit 0). Теперь лимит равен сумме констант 10000 + 20 + 1 + 1 (MAX_B2E_SIGNER_MEMBERS и соседние).
• С 26.500.0 sign передаёт сервису подписи пол участника. Для этого Configure\Member получил параметр ?string $gender, а в MemberRepository::USER_CACHE_FIELDS добавлено PERSONAL_GENDER. Для нового поля «ФИО целиком» (FieldType::FULL_NAME = 'fullname') модуль досылает части ФИО при конфигурировании документа и при заполнении полей.
• В 26.600.0 плейсхолдеры проходят фильтр «проверенных» алиасов (FieldAliasService::toVerifiedAlias()). Выключатель у него тоже есть, это опция ~disable_placeholder_verified_alias_filter (Config\Storage::isPlaceholderVerifiedAliasFilterDisabled()).
• Service\Integration\Crm\AccessService::canCurrentUserViewDocument() добавили в 26.500.0, и до 26.600.0 включительно его никто не вызывает.
• B2eSignedFile::downloadAction для несуществующего участника теперь отвечает ошибкой SIGN_DOCUMENT_NOT_FOUND вместо обращения к null.
• В 26.600.0 в модуле появился первый TypeScript, 15 файлов .ts и .d.ts в install/js/sign/v2/grid/components/*.
• В комментариях попадаются внутренние идентификаторы требований: «NORMATIVE ALG-01» в BaseRule, «SC-001» и «SC_002» в ReceiptScenario и ResultFile/Save.php.
• Бандлы company-selector, document-template-filling, analytics и type в 26.450.0 пересобраны другим сборщиком. Из company-selector.bundle.js ушли все 406 строк с babelHelpers.classPrivateFieldLooseKey, var сменился на const, отступы стали табами. Отсюда тысячи строк в диффе при паре десятков строк правок в src/.
• Остальные изменения сигнатур в 26.600.0 добавляют необязательные параметры в конец и вызывающий код не ломают: Item\Member::__construct(..., ?int $folderId = null, ?int $createdById = null), Item\Company::__construct(..., bool $goskeyLiteAvailable = false), CreateGroupChatResult::__construct(int $chatId, ?string $warning = null), а также конструкторы PlaceholderCacheService, PlaceholderCollectorService, FieldAliasService, TemplateService, Template\Complete и SignersListService.
• Config\Storage::getMaxB2bDocumentsSignedWithoutRestriction() по умолчанию возвращает 0 вместо 2. Читает его только Restriction::isPhoneVerificationRequiredForB2b(), а тот без модуля bitrix24 отдаёт false, так что коробку это не касается.
• Deprecated нет ни в одной из трёх версий.

Что делать

• Обновите sign хотя бы до 26.500.0. Раньше условия LogicOr/LogicAnd в AccessCheck без ID в JSON-теле проверяли только общее право.
• Поищите в своём коде isEntityId, createDocumentChat, new Send(, new FixDismissalPresetTemplate(, isOptionsReloaded, вызовы InstallEvents() у модуля sign и реализации PreloadableStrategyInterface.
• Проверьте, что фронтенд и скрипты не передают ID документа одновременно в строке запроса и в теле.
• Если ваш код наполняет группы подписантов, отсейте уволенных и экстранет-пользователей до запроса.
• Прогоните sign.b2e.mysafe.tail до и после обновления и сравните выдачу.
• Настройте логгер sign.<channel> или опцию log_<channel>_level, если журнал ошибок sign вам нужен.
• После обновления убедитесь, что таблицы b_sign_document_folder, b_sign_document_folder_relation и b_sign_signers_list_user_option созданы.
• Перед увольнением сотрудника посмотрите, в каких шаблонах он участвует.