← Назад к заметкам

Заметки

Почему нельзя отключать проверку прав ради чат-бота

Почему нельзя отключать проверку прав ради чат-бота: Риски прямого доступа к HL/IBLOCK.

Почему нельзя отключать проверку прав ради чат-бота. Основной фокус: Риски прямого доступа к HL/IBLOCK.

Задача

Разобрать практический сценарий в Bitrix24 без лишней теории.

Задача — почему нельзя отключать проверку прав ради чат-бота. Риски прямого доступа к HL/IBLOCK.

Главное — не искать один универсальный метод, а сначала определить сущность, права и слой API, через который выполняется действие.

Как это устроено

В Bitrix24 похожие действия часто проходят через разные уровни: интерфейс, REST, D7, события, права и фоновые агенты. Важно понимать, какой слой отвечает за конкретный результат.

В Bitrix24 права почти всегда считаются не одной настройкой, а комбинацией роли, группы, структуры, владельца, привязки к сущности и контекста текущего пользователя.

Если сценарий проверяется под администратором, отдельно повторите его под обычным пользователем. Для прав, CRM, задач, Диска и приложений это часто даёт другой результат.

Рабочий подход

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

Сделайте минимальный тест на одной сущности, сохраните входные данные и ответ метода, а затем расширяйте решение на массовый сценарий.

На коробке удобнее добавлять временное логирование рядом с местом выполнения кода, а в облаке — сохранять входящие и исходящие REST-запросы в свой журнал интеграции.

Частые ошибки

Частая ошибка — переносить решение из одной сущности в другую без проверки ID, типа владельца, прав и включённых модулей.

  • Проверять сценарий только под администратором и не видеть проблему прав обычного пользователя.
  • Пытаться решить доступ скрытием элемента интерфейса, хотя данные остаются доступны через другой путь.
  • Не логировать фактический запрос и ответ, из-за чего ошибка выглядит случайной.