---

[I128-2808] Защита публичных каналов AbuseProtection

---

НАЧАЛО >> Оглавление >> Общее описание >> История изменений >> Что нового в проекте I128 >> Версия 2026.3 >> [I128-2808] Защита публичных каналов AbuseProtection📄 Скачать в DOCX

---

Тип	Версия	Статус	Приоритет	Исполнитель
⚙️ Новые возможности	2026.3	🔘 Завершено	Средний	Ilya Mikhaylenko

Компоненты: Нет

Завершено: 08.09.2026 12:24

1. Цель

Нужно создать общесистемный модуль AbuseProtection для защиты публичных форм, входящих сообщений и внешних каналов от спама, повторов, злоупотреблений и автоматизированной отправки. Модуль должен принимать решение allow, challenge, throttle, quarantine или reject и возвращать безопасный результат для пользователя и диагностический результат для администратора.

1. Контекст

TaskPortal, публичные WorkflowScreenформы, входящая почта, мессенджеры и webhooks не должны реализовывать собственные частные antispam проверки. Защита публичного приема должна быть единой: rate limit, captcha или другой challenge, replay protection, fingerprint, allow/deny list, quarantine, incident log, retention и HealthCheck.

AbuseProtection не заменяет Security. Пользователь может иметь право на действие, но действие все равно может быть задержано, отправлено в quarantine или отклонено по policy защиты канала.

1. Что Нужно Сделать

Нужно реализовать сущности AbuseProtectionPolicy, AbuseProtectionRule, AbuseProtectionDecision, AbuseProtectionIncident, AbuseProtectionFingerprint, AbuseProtectionChallenge и AbuseProtectionRetentionPolicy.

Policy должна применяться к публичной форме, host, проекту, типу обращения, внешнему каналу, пользователю, IP, session, email или другому безопасному ключу. Rule должна описывать rate limit, challenge, replay protection, fingerprint, allow/deny list, quarantine и исключения.

Нужно реализовать decision API, который получает контекст действия и возвращает машинно читаемое решение: allow, challenge, throttle, quarantine или reject. Решение должно содержать безопасный текст для пользователя, диагностическую причину для администратора и trace id.

Нужно реализовать replay protection и idempotency для повторной отправки формы, повторного webhook, повторного письма или повторного действия портала. Повтор не должен создавать дубли задач, комментариев, вложений и событий.

Нужно реализовать quarantine: подозрительное обращение, сообщение или вложение может быть сохранено в контролируемое состояние для проверки, но не должно попадать в штатный workflow как доверенное действие.

Нужно реализовать incident log с retention и маскированием. Диагностика не должна хранить лишние персональные данные в открытом виде; IP, email, user-agent и внешние идентификаторы должны храниться только по policy.

Нужно интегрироваться с WorkflowScreen/WorkflowView, TaskPortal, Tasks, EventBus, Queue, Security, HealthCheck и TestA. Доменные модули выбирают policy и передают контекст, но не реализуют собственный engine защиты.

1. Границы Ответственности

AbuseProtection владеет системными anti-abuse policy, правилами, решениями, challenge, replay protection, fingerprint, quarantine, incident log, retention и диагностикой.

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

1. Критерии Приемки

Публичная форма может вызвать AbuseProtection до создания задачи, комментария, вложения или workflow-действия.

Для нормального действия возвращается allow, для превышения лимита throttle, для требующей проверки ситуации challenge или quarantine, для запрещенной ситуации reject.

Повторная отправка формы или webhook не создает дубли и получает предсказуемый результат.

Incident log доступен администратору с учетом прав и маскирования, но не раскрывает лишние персональные данные.

HealthCheck находит опубликованные публичные формы и каналы без назначенной policy или с некорректной policy.

1. Проверки И Документация

TestA должен проверять allow, challenge, throttle, quarantine, reject, replay protection, безопасное сообщение пользователю, incident log, retention/masking и интеграцию с публичной формой.

Help должен описывать настройку policy, правила, решения, quarantine, диагностику, права просмотра incidents и типовые сценарии публичных форм.

-

Реализован первый контрактный срез общесистемного модуля AbuseProtection.

Состав:

• module shell и административный контракт AbuseProtectionPolicy;
• SID runtime-схема для policies, rules, counters, challenges, incidents, fingerprints, idempotency и audit;
• system JSON с решениями allow/challenge/throttle/quarantine/reject, типами правил, default policy, событиями и API-схемами;
• __call API: RegisterPolicy/GetPolicy/EvaluateRequest/BuildFingerprint/CreateChallenge/VerifyChallenge/RecordIncident/GetIncidents/HealthCheck;
• Help для администратора, разработчика и эксплуатации;
• TestA saferead и dryrun lifecycle.

Проверки:

• PHP lint для всех .php/.inc модуля AbuseProtection;
• JSON parse system/abuseprotection.json;
• TestA AbuseProtection safe-read: 1/1;
• TestA AbuseProtection safe-read+writes+queue allowUnsafe: 2/2;
• TestA structural AbuseProtection safe-read: 16/16;
• git diff -cached -check.

Границы: AbuseProtection не реализует Security, EventBus, Queue, WorkflowScreen, WorkflowView, TaskPortal или доменную логику Tasks. Внешние модули остаются контрактами-потребителями/поставщиками.

1. Связанные задачи

1.1. 🔗 blocks: I128-2811

1.2. 🔗 blocks: I128-2827

1.3. 🔗 blocks: I128-2793

1.4. 🔗 blocks: I128-2794

1.5. 🔗 blocks: I128-2795

1.6. 🔗 blocks: I128-2797

1.7. 🔗 blocks: I128-2798

1.8. 🔗 blocks: I128-2799