Разбор системы комментариев: ветки, состояния модерации и содержимое для повторного рендеринга

Цель

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

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

Идентификация авторов, политика модерации (до публикации для новых аккаунтов, после публикации для доверенных) и выбранный формат ввода (обычный текст или подмножество Markdown).

Шаги

1. Ограничения: никогда не хранить готовый HTML как источник истины; удаление комментария не должно разрушать ответы под ним; для каждого действия модерации можно установить исполнителя; чтение постраничное и недорогое.
2. Компоненты: API записи с ограничениями частоты для каждого автора; хранилище; рендерер, преобразующий исходный текст в HTML при чтении и помещающий результат в кэш, который можно отбросить; очередь модерации; конечная точка для жалоб; аудит действий.
3. Модель данных: comment(id, thread_id, parent_id, path, depth, author_id, body_source, status: pending|visible|hidden|removed, created_at, edited_at); comment_revision(comment_id, body_source, edited_at); report(comment_id, reporter_id, reason, at); moderation_action(comment_id, moderator_id, action, reason, at). Материализованный path из идентификаторов предков с ограничением глубины обеспечивает недорогое чтение поддеревьев; разбивайте комментарии верхнего уровня на страницы по (created_at, id) и загружайте ответы для каждой страницы.
4. Рендеринг: считайте body_source авторитетным источником и обрабатывайте его конвейером очистки, результат которого — только кэш. Памятка OWASP по XSS указывает, что очистка HTML удаляет опасный HTML и возвращает безопасную строку, а способы обхода санитайзеров обнаруживают регулярно, поэтому библиотеку необходимо обновлять исправлениями; хранение готового HTML навсегда закрепило бы в данных каждый прежний обход защиты.
5. Состояния модерации: pending виден только автору; hidden сохраняет узел с заглушкой; removed по инициативе автора сохраняет узел, если у него есть дочерние, и удаляет его в противном случае. Направляйте в очередь по доверию к автору, числу жалоб и простым эвристикам (ссылки, повторяющийся текст).
6. Сбои: записи слишком долго ждут в очереди (приоритет по возрасту, оповещение о возрасте); скоординированные массовые жалобы (учитывать историю жалующихся, требовать достижения порога перед автоматическим скрытием); очень глубокие ветки (ограничение глубины и ссылка «продолжить эту ветку»); правки после одобрения (возвращать в очередь, если текст существенно изменён); удаление аккаунта автором (псевдонимизировать автора, сохранить узел).
7. Измеряйте: время в pending, жалобы на тысячу комментариев, долю скрытых после жалобы, действия модераторов в день, ошибки рендерера.
8. Не в первую очередь: голоса и ранжирование, обновления в реальном времени, модель спама на основе машинного обучения, уровни репутации, расширенные встраиваемые материалы, реакции.

Ожидаемый результат

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

Ограничения и основание проверки

Предлагаемый проект, без измерений. Правила кодирования вывода изложены в статье об XSS; этот разбор охватывает сервис вокруг них.