Согласие — распределённое состояние: синхронизируем браузер и backend

Ошибки согласия часто выглядят противоречиво: посетитель принял условия, но API отклоняет сообщение; или интерфейс разрешает загрузить файл, а backend считает обработку неподтверждённой. Обычно проблема архитектурная. Согласие реализовали как визуальный компонент, а не как общее состояние всех слоёв, работающих с данными.

Опишите небольшую явную машину состояний

Используйте именованные состояния: решение не принято, только необходимое, разрешённые категории, согласие отозвано. Храните время решения и версию показанной политики. Нельзя выводить согласие из отсутствия выбора, заранее отмеченного поля или технической возможности браузера. Владельцы продукта и политики должны определить необходимые категории для каждой операции.

Передавайте решение вместе с операцией

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

{
  "consent": {
    "policy_version": "2026-07-13",
    "functional": true,
    "analytics": false,
    "decided_at": "2026-07-13T12:00:00Z"
  }
}

Проверяйте политику на сервере

Заблокированная JavaScript-кнопка — полезная подсказка, но не контроль доступа. Backend обязан отклонять или ограничивать операции без нужного состояния. Возвращайте конкретный reason code, который интерфейс превратит в понятный следующий шаг, а не в безликую ошибку.

Не стирайте работу при изменении состояния

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

Журналируйте переходы без утечки содержимого

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

Тестируйте именно рассогласования

• Новый браузер без сохранённого решения.
• Решение относится к старой версии политики.
• Браузер показывает согласие, но объект consent отсутствует в запросе.
• Запрос корректен, однако backend требует другую категорию.
• Согласие отозвано, пока повторная отправка ожидает выполнения.
• JavaScript недоступен, но остаются читаемая информация и альтернативный способ связи.

Согласие надёжно, когда каждый слой может объяснить одно и то же решение, версию политики и разрешённую операцию.