Аудит кода и архитектуры

Метод и охват

19.10.2026 получена копия кода в режиме чтения с 79.137.222.136: document root /home/bitrix/ext_www/servicedesk.artron.ru, плюс общие local/php_interface/sd, local/templates/servicedesk, local/modules/artron.servicedesk. Копия исходников находится только во временном закрытом каталоге анализа и не включена в этот пакет: в коде есть секрет интеграции. Доказательства ниже ссылаются на исходные пути и строки текущего среза. Просмотрены основные маршруты, обработчики изменений, функции SLA, уведомления, интеграция QR/CRM и UI-шаблон. Аудит не равен полному динамическому тесту всех веток.

Авторизованный браузерный просмотр через /bitrix/admin/ подтвердил загрузку /tickets/, /admin/, /create/, /engineer/, карточки в /admin/control/ и /tickets/info/. / после входа перенаправляет администратора на /admin/. Неавторизованный GET /, /tickets/, /create/ отвечает HTTP 500; /bitrix/admin/ — HTTP 200. /call/ без объекта отвечает 200, в консоли ошибка Bitrix Pull could not read push-server config; это не доказательство сбоя CRM-формы для корректного QR-кода. Запросы только GET, без изменяющих параметров.

Архитектура и данные

Слой	Текущее устройство	Следствие
Хостинг	Сайт `sd` в общей установке Битрикс; `bitrix`, `local`, `upload` — общие ссылки	Изменения shared-кода могут затронуть другие сайты Artron
Представление	`local/templates/servicedesk`, страницы с большим объёмом PHP и HTML	Сложно отделить правила доступа, данные и верстку
Домен	`function.php` (~1136 строк), `local/php_interface/sd/init.php` (~500), `/admin/control/index.php` (1384)	Изменение одного сценария затрагивает много условий
Хранилище	Инфоблоки 29 компании, 30 договоры, 31 оборудование, 32 обращения, 33 история, 34 инженеры, 54 настройки уведомлений	Бизнес-данные и связи держатся на свойствах и числовых ID
Фоновая работа	Почтовая отправка в `sendSDNotice`; статистика в `stat.php`; интеграция CRM в `/call/`	Нужна наблюдаемость и проверка фактических доставок
Экспериментальный модуль	`local/modules/artron.servicedesk` версии 0.0.1	Предыдущий аудит утверждает, что он не установлен; в этом срезе установка через БД не перепроверена

В предыдущем аудите были приведены объёмы 17/16/2214/3069/36149/15/151 элементов по инфоблокам. Это срез предыдущей проверки, не текущие показатели; для планирования миграции количество нужно пересчитать на дату выгрузки.

Подтверждённые дефекты и риски

Приоритет: P0 — доступ или целостность; P1 — сломанный основной сценарий; P2 — качество сопровождения/UX.

ID	Приоритет	Доказательство	Вывод и предел доказательства
C-01	P1	Неавторизованный `GET /` → 500. `index.php:2-3` задаёт `NEED_AUTH` до header; `local/templates/servicedesk/footer.php:23` обращается к `SD_PROP_ID_CODE_CLOSE`	Обычный путь входа недоступен. Порядок инициализации константы — вероятная непосредственная причина; подтвердить стеком PHP при исправлении. Через `/bitrix/admin/` вход работает.
C-02	P0	`tickets/info/update.php:9-22`, `update2.php:9-22` пишут свойство по `$_REQUEST['id']`; нет локальной проверки HTTP-метода, `check_bitrix_sessid`, роли и связи обращения с доступным договором	Дефект защитных проверок в коде подтверждён; возможность эксплуатации конкретной ролью не проверялась.
C-03	P0	`admin/control/update.php:19-26` использует `$_REQUEST['field']` и `id` до allowlist/проверки доступа; `:130` пишет историю	Поле и объект нельзя доверять запросу. Наличие массива допустимых полей ниже по файлу не ограничивает первичную запись.
C-04	P0	`tickets/info/index.php:116-139` закрывает по GET `close=yes`; `admin/control/index.php:202-221` меняет статус/отправляет событие по GET; `set_now_time.php:7-64` пишет время по `$_REQUEST`	Изменение по ссылке создаёт риск повторов, случайного перехода и CSRF. Для клиентской карточки фильтр договора есть в `:85-110`, но закрытие и отдельные endpoints требуют проверки после загрузки объекта.
C-05	P0	`create/index.php:118-265`: номер `getMaxNumber()+1`; договор берётся из параметра `contract`, после SQL-проверки связи объекта с договором нет явного сравнения с разрешённым пользователю набором	Возможна гонка номеров; проверка принадлежности выбранного договора недостаточно явная. Нужны тесты на чужой договор до любого утверждения об эксплуатации.
C-06	P1	`tickets/index.php:438` и `admin/index.php:328` подключают PHPExcel; путь `/home/bitrix/www/PHPExcel/PHPExcel.php` и ссылка сайта отсутствуют при проверке `test -e`	Экспорт по текущему пути не может подключить библиотеку. Сам запрос экспорта не запускался.
C-07	P1	`stat.php:1-10` задаёт `DOCUMENT_ROOT=/home/bitrix/servicedesk`; каталог отсутствует	При прямом запуске с этим значением загрузка пролога не сработает. Наличие/владелец актуального cron в этом срезе не подтверждены.
C-08	P0	`call/index.php:10-20` держит REST credential в исходнике и выключает `CURLOPT_SSL_VERIFYPEER`	Риск раскрытия ключа и невалидированной TLS-связи. Сам ключ здесь намеренно не приводится. Требуются инвентаризация потребителей и ротация.
C-09	P1	`engineer/set_time.php:44-50` вызывает запись при `GET setTime=yes` по специальному коду; `/engineer/index.php` не задаёт `NEED_AUTH`	Действие доступно по bearer-ссылке. Сила и срок жизни кода не оценены; маршрут требует явной модели доверия и защиты от повторов.
C-10	P2	`update-set.php:4-11` изменяет уведомления по `$_REQUEST` без sessid; `userInit()` при авторизации создаёт элементы инфоблока 54 (`init.php:5-53`)	Чтение/вход может иметь побочный эффект записи настроек; уведомления требуют отдельной политики и метода POST.
C-11	P2	`function.php:927-930` содержит немедленный `return` в `sendMailToUsers`, но `init.php:307+` реализует `sendSDNotice`	Одна ветка почты отключена; утверждать, что вся почта не работает, нельзя. Для каждого события нужна карта отправителя и получателя.
C-12	P2	`/testxxx.php`, `/admin/testxxx.php` остаются в document root и выводят внутренние данные; `/call/dourl.php` формирует QR URL; `.access.php` имеет явные правила только для `/`, `index.php`, `call`	Тестовые/служебные маршруты требуют инвентаризации и ограничения/удаления после проверки зависимостей. Эти GET-маршруты специально не вызывались.

Причины сложности и направления ремонта

Числовые ID и смешанный доступ к данным. lib_def.php содержит ID инфоблоков, свойств, enum и групп; function.php и страницы используют одновременно CIBlockElement и SQL к b_iblock_element_prop_s*. Ввести централизованный реестр схемы с проверкой при старте/деплое и репозитории для чтения, не меняя сразу хранилище.
Логика и HTML в одних файлах. Сначала вынести проверку роли/договора, команды изменения обращения и расчёт SLA в локальный доменный слой; оставить публичные URL совместимыми. Шаблоны сделать только представлением.
Нет явной атомарности. Создание обращения, номера, истории и уведомлений идёт последовательными действиями (create/index.php:118-266, function.php:10-40). Нужны транзакция для данных, уникальный индекс/источник номера и очередь отправки после commit.
История — отдельно, но не гарантированно согласована. writeLogRequest() создаёт запись в инфоблоке 33, результат вызова не везде проверяется. Логи изменений надо создавать в одной транзакции с командой и хранить старое/новое значения структурно; для старых записей оставить адаптер чтения.
SLA — собственный алгоритм. calculateDTime() и calculateDTime3() в function.php:420-620, getHoliday():621+; договор даёт график и сроки. Перед рефакторингом зафиксировать таблицу примеров и текущие результаты на копии данных, включая переносы/праздники/смену часового пояса.
Интеграции без прозрачного контракта. Идентификаторы 1С в свойствах подтверждают модель обмена, но источник, расписание и обратная синхронизация не установлены. CRM вызов и форма есть в /call/; фактическое создание сделки в проверенном UI не наблюдалось.

Непроверенное и ограничения

Клиентская, менеджерская и инженерная роли не были доступны для авторизованного end-to-end теста; admin может обходить часть ограничений.
Не выполнялись POST/GET запросы с изменяющими параметрами, экспорт, почтовая отправка, QR-ссылки с реальным кодом и нагрузочные тесты.
Состояние БД/cron/очередей и логи PHP не выгружались в этом срезе. Показатели и cron из прежнего аудита использовать как исходные подсказки.
Консольная ошибка Bitrix Pull на /call/ зафиксирована без признаков, что она ломает конкретную CRM-форму. Проверять корректный QR-сценарий отдельно.