Улучшение безопасности и обработки ошибок #8

Closed
opened 2026-04-26 22:39:55 +03:00 by aleksey · 1 comment
Owner
  • При блокировке/отклонении принимать и сохранять reason
    Во все методы, изменяющие статус (блокировка пользователя, отклонение события, жалобы), добавить обязательное поле reason и сохранять в БД. Сохранять событие в аудит.

  • CORS-заголовки для админского сервера
    Убедиться, что порт 8445 отдаёт Access-Control-Expose-Headers: Content-Range . Если нужно, добавить.

  • Валидация входных данных
    Особенно для создания/редактирования сущностей (email, обязательные поля).

- [ ] **При блокировке/отклонении принимать и сохранять `reason`** Во все методы, изменяющие статус (блокировка пользователя, отклонение события, жалобы), добавить обязательное поле `reason` и сохранять в БД. Сохранять событие в аудит. - [ ] **CORS-заголовки для админского сервера** Убедиться, что порт 8445 отдаёт `Access-Control-Expose-Headers: Content-Range` . Если нужно, добавить. - [ ] **Валидация входных данных** Особенно для создания/редактирования сущностей (email, обязательные поля).
aleksey added the Future label 2026-04-26 22:39:55 +03:00
Author
Owner

🧩 Этап 1: Сохранение reason и запись в аудит
Это самый объёмный пункт. Я предоставлю готовые изменённые файлы для ключевых обработчиков. Остальные будут аналогичными.

Шаги:

В обработчиках, которые меняют статус (модерация, блокировка, обновление жалоб/отзывов/тикетов), добавить извлечение поля reason из тела запроса.

Сделать reason обязательным для действий block, unblock, freeze, unfreeze, а также при изменении статуса жалобы/отзыва (опционально — можно везде обязательным, где это логично).

После успешного изменения вызвать core_admin_audit:log(...) с передачей reason.

Обновить юнит-тесты и API-тесты.

Изменяемые файлы (примеры):

admin_handler_moderation.erl

admin_handler_user_by_id.erl

admin_handler_reports.erl

admin_handler_report_by_id.erl

admin_handler_reviews.erl

admin_handler_tickets.erl

admin_handler_ticket_by_id.erl

После внесения изменений запустить make eunit, чтобы убедиться, что тесты проходят с учётом нового поля.

🧩 Этап 2: CORS-заголовки
Добавить Access-Control-Expose-Headers: Content-Range в ответы всех админских обработчиков. Это можно сделать централизованно, изменив функции send_json и send_error в каждом обработчике (или вынести в общий модуль). Но так как каждый обработчик уже содержит свои send_json/send_error, проще добавить заголовок прямо в них.

Изменяемые файлы: все admin_handler_*.erl.

Проверка: отправить запрос через curl и убедиться, что заголовок присутствует.

🧩 Этап 3: Валидация входных данных
Добавить недостающие проверки в обработчики:

При создании администратора (admin_handler_admins) — проверять email, password, role.

При создании подписки (admin_handler_subscriptions) — user_id, plan.

При создании banned word — непустое слово.

При создании тикета — error_message.

При обновлении любой сущности — проверять, что передано хотя бы одно поле.

Изменяемые файлы: admin_handler_admins.erl, admin_handler_subscriptions.erl, admin_handler_banned_words.erl, admin_handler_tickets.erl и др.

Юнит-тесты: добавить кейсы с отсутствующими обязательными полями и проверить возврат 400.

🧩 Этап 4: Финальное тестирование
Запустить полный набор юнит-тестов (make eunit) и интеграционных (make test-api).

Исправить возможные падения из-за новых полей.

Убедиться, что все тесты проходят.

🧩 Этап 1: Сохранение reason и запись в аудит Это самый объёмный пункт. Я предоставлю готовые изменённые файлы для ключевых обработчиков. Остальные будут аналогичными. Шаги: В обработчиках, которые меняют статус (модерация, блокировка, обновление жалоб/отзывов/тикетов), добавить извлечение поля reason из тела запроса. Сделать reason обязательным для действий block, unblock, freeze, unfreeze, а также при изменении статуса жалобы/отзыва (опционально — можно везде обязательным, где это логично). После успешного изменения вызвать core_admin_audit:log(...) с передачей reason. Обновить юнит-тесты и API-тесты. Изменяемые файлы (примеры): admin_handler_moderation.erl admin_handler_user_by_id.erl admin_handler_reports.erl admin_handler_report_by_id.erl admin_handler_reviews.erl admin_handler_tickets.erl admin_handler_ticket_by_id.erl После внесения изменений запустить make eunit, чтобы убедиться, что тесты проходят с учётом нового поля. 🧩 Этап 2: CORS-заголовки Добавить Access-Control-Expose-Headers: Content-Range в ответы всех админских обработчиков. Это можно сделать централизованно, изменив функции send_json и send_error в каждом обработчике (или вынести в общий модуль). Но так как каждый обработчик уже содержит свои send_json/send_error, проще добавить заголовок прямо в них. Изменяемые файлы: все admin_handler_*.erl. Проверка: отправить запрос через curl и убедиться, что заголовок присутствует. 🧩 Этап 3: Валидация входных данных Добавить недостающие проверки в обработчики: При создании администратора (admin_handler_admins) — проверять email, password, role. При создании подписки (admin_handler_subscriptions) — user_id, plan. При создании banned word — непустое слово. При создании тикета — error_message. При обновлении любой сущности — проверять, что передано хотя бы одно поле. Изменяемые файлы: admin_handler_admins.erl, admin_handler_subscriptions.erl, admin_handler_banned_words.erl, admin_handler_tickets.erl и др. Юнит-тесты: добавить кейсы с отсутствующими обязательными полями и проверить возврат 400. 🧩 Этап 4: Финальное тестирование Запустить полный набор юнит-тестов (make eunit) и интеграционных (make test-api). Исправить возможные падения из-за новых полей. Убедиться, что все тесты проходят.
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Reference: EventHub/EventHubBack#8