han-app/backlog.md

Закрыто 21.07-27.07

MVP frontend: один чат с компанией без истории диалогов; пункт «Чат» открывает текущий активный диалог или создаёт его при отсутствии

При создании пользователя номер телефона копировать в профиль Russian_Phone

Убрать хеширование устройства клиента в devise_json - хочу видеть его параметры.

Добавить параметр, ограничивающих кол-во неуспешных попыток ввода смс.

Поправить чтение сообщений от Битрикса. Сейчас они выглядят так: "[b]Антон Пичугин:[/b] [br]опять ты?" Надо убрать из текста сообщения Отправителя в битриксе

Если неавторизованный пользователь вводит сообщение, после отправки идет на регистрацию, после окончания регистрации его сообщение пропадает. Надо чтобы сохранялось и отправлялось (по аналогии с нажатием на кнопку из раздела "Популярные вопросы")

Изменение в БД по аудитам (заполнение IP, сквозное заполнение UserSession)

Яндекс.капчу добавить

Формы согласий поправить (Согласие на обработку ПД + Политика, Пользовательское соглашение, Реклама)

При повторном запросе OTP кода при авторизации не нужно указывать ошибку "Новый код заказан. Предыдущий код больше не действует."

Интеграция с СМС-провайдером — спецификация и план rollout зафиксированы в modules/module-11-idgtl-sms.md; пункт не закрыт до реализации sms-service/worker, Keycloak lifecycle, schema sms, callback/nginx, env validation, observability и общего DoD. Production prerequisites: согласованные sender/template, Direct TOKEN_1, callback credentials/подтверждённый source IP и статический egress IP.

Моделирование уведомлений — постановка v6 синхронизирована с functional_blocks (business logic)/notification-requirements.md, arch-00…05 и module-01/03/07. Зафиксированы: instruction только в новой вкладке; TTL только при отсутствии date_expired; первое скачивание любого связанного документа скрывает; producer_test только для smoke, secret/hash раздельно.

Кнопка "Позвонить оператору" (ссылка tel:+74999591007)

На главном экране две кнопки: чат и звонок оператору. На кнопке с чатом уведомление при наличии непрочитанных сообщений.

Закрыто 28.07-03.08

Подключить OTLP-провайдер

Отправлять на UI информацию разные ошибки при попытках авторизации в зависимости от события: код неверен, истёк или уже использован; превышен лимит попыток авторизации, попробуйте через 24 часа (в случаях превышения otp.phone.max_send_attempts_per_24h); превышен лимит неуспешных авторизаций, начните процедуру заново (в случае превышения otp.phone.max_verify_attempts).

При отрицательном результате проверки сообщения через message-safety, если сообщение отправлялось с главного экрана, то пользователь не переводится в чат, ему под окном главного экрана выпадает сообщение об ошибке. Не на всех устройствах это видно. Воспринимается как UX-дефект. Как надо: вне зависимости от решения message-safety, если пользователь отправил сообщение, то он переводится на экран с чатом. Далее, сейчас отрицательный результат message-safety выводится пользователю как техническая ошибка (красным цветом под полем ввода сообщения) и опять же воспринимается не как бизнес-логика, а как техническая ошибка. Это поведение нужно поменять. Если сообщение пользователя не прошло проверку, нужно ему в окне чата прислать ответ: Для сообщений: К сожалению, ваше сообщение не соответствует правилам данного чата и не может быть отправлено. Попробуйте переформулировать. Для документов: К сожалению, ваш документ не прошел проверку и не может быть доставлен.

UX-дефект: frontend показывает «Не удалось завершить вход» при ошибке отправки отложенного сообщения, хотя вход завершён. Это следует исправить: завершать экран авторизации после bootstrap, а ошибку Bitrix показывать уже в чате (если сообщение отклонено сервисом message-safety, учесть реализацию предыдущего пункта)

Ограничить кол-во символов в сообщении на фронте. Показывать в моменте счетчик: n/max, где n сколько символов уже напечатано, max сколько может быть отправлено. Максимальное кол-во символов - положить в app_settings.

Убрать с экрана ввода номера телефона тексты согласий внизу экрана: Нажимая «Получить код», вы соглашаетесь с условиями использования и политикой конфиденциальности. Согласия пользователь дает ранее на отдельном экране.

Перенести секреты из .env в KM Selectel.

Провести аудит безопасности вм

Унифицированы гостевые экраны Центра уведомлений, Профиля и Чата: единый стиль сообщения о необходимости входа и кнопка «Авторизоваться».

В разработку:

2. После интеграции с смс провайдером, реализовать debounce механизм при авторизации - каждая след. смс можно отправить через все большее окно.
3. Store-review вход: точечный bypass в Keycloak OTP SPI по номеру из .env (STORE_REVIEW_ENABLED / STORE_REVIEW_PHONE / STORE_REVIEW_OTP) — для этого телефона SMS не шлётся, verify принимает фиксированный OTP; остальные номера идут обычным OTP/SMS. Не путать с глобальным KEYCLOAK_OTP_MOCK_*. Учётные данные только в Review Notes стора (не в бинарнике/UI); пользователь с демо-контентом; в production включать только на время ревью.
4. Хранить историю устройств, с которых пользователь входил в ЛК (Ид юзера, идентификатор устройства, дата последнего входа, способ входа - веб\приложение)
5. Веб-пуши для PWA
6. На кнопке Чат отображать значок наличия непрочитанных уведомлений. Требуется синхронизация между устройствами (решение, например через Dialog.client_last_opened_at)
7. Описание бизнес сущностей: Пользователь
8. Описание бизнес сущностей: Сообщение
9. Вынести за пределы ВМ1 сервисы message-safety и sync-service.
10. Сделать страницу с инструкцией по установке приложения
11. Написать пользовательское соглашение.
12. Разработка message-safety
13. Разработка sync-service
14. Разработка notification-service
15. Поднять второй контур для продакшн
16. Спрятать сеть за балансировщиком нагрузки
17. Автопродление TLS падает при перезагрузке nginx; сертификат действует до 14.10.2026. (Исправить reload внутри контейнера и проверить systemctl start an-chat-ssl-renew.service до успешного завершения.)
18. WireGuard-only SSH.
19. Запрет входа под root: В /etc/ssh/sshd_config установите PermitRootLogin no. Заходите под обычным пользователем (например, deploy) и используйте sudo для админских задач.
20. Удалите все ненужные пакеты, компиляторы (gcc, make) и сервисы. Чем меньше программ на сервере, тем меньше потенциальных уязвимостей.
21. Монтирование с флагами безопасности: Разделы диска (особенно /tmp и /var/tmp) следует монтировать с флагами noexec (запрет запуска исполняемых файлов) и nosuid (игнорирование битов setuid).
22. Systemd-ограничения: используйте директивы в юните NoNewPrivileges=yes # Запрещает повышение привилегий через setuid ProtectSystem=strict # Делает всю ОС доступной только для чтения PrivateTmp=yes # Дает процессу свой изолированный /tmp ProtectHome=yes # Скрывает домашние директории пользователей
23. Добавить логи (Для Python-сервисов добавить OTLP Log Exporter: api-backend; sms-service; sms-worker. Подключить LoggerProvider, BatchLogRecordProcessor и bounded queue. Передавать resource attributes: service.name; service.version; deployment.environment; service.namespace=han-chat.) Экспортировать структурированные поля request_id, trace_id, span_id, severity и event name. Оставить stdout как аварийный локальный журнал. Добавить canary-тесты, запрещающие экспорт токенов, cookie, телефонов, email, текстов сообщений, SQL и object keys.).
24. Nginx metrics/tracing в signoz

На будущее (после доработки отдельных функциональностей):

1. Определение итогового перечня мнемоник, перевод фронтенда на мнемоники, seed заливка мнемоник в БД (?)
2. Моделирование профиля клиента.
3. Реализовать в полноценном bitrix-sync обработчик document.client_uploaded: claim/retry/DLQ, идемпотентность по client_document_id, группировка по submission_id; до этого stub задачи не claim-ит.

На анализ: debounce на отправку СМС (сейчас есть Фиксированный cooldownmin_seconds_between_attempts)

Критично для релиза:

1. Разработка message-safety
2. Разработка sync-service
3. Пользовательское соглашение
4. Разработка notification-service
5. Подключить OTLP-провайдер
6. Починить баги
7. Второй контур для продакшн

Переезд на тестовый домен

Нет — одного .env и новых сертификатов недостаточно.

Нужно пройти цепочку:

1. DNS

A-запись нового домена → IP ВМ (до выпуска сертификата).

2. .env — не одно поле, а все публичные URL

• PUBLIC_HOST, PUBLIC_WEB_URL, PUBLIC_API_URL, PUBLIC_AUTH_URL
• KEYCLOAK_PUBLIC_URL
• NGINX_TLS_CERTIFICATE / NGINX_TLS_CERTIFICATE_KEY (путь /etc/letsencrypt/live/<новый-домен>/...)
• BITRIX_PUBLIC_BASE_URL
• IDGTL_SMS_CALLBACK_PUBLIC_URL (если SMS уже подключён)

3. Сертификат

Certbot на новый -d / --cert-name, затем nginx с TLS.

4. Пересборка / перезапуск сервисов

• frontend-static — URL зашиты на build (EXPO_PUBLIC_* из PUBLIC_WEB_URL / PUBLIC_AUTH_URL)
• keycloak — KC_HOSTNAME из KEYCLOAK_PUBLIC_URL
• nginx, api-backend и связанные сервисы — подхватить новый env

5. Настройки в БД (seed / app-settings)

В app-settings.production-like.yaml:

• security.cors.allowed_origins → https://новый-домен
• notification.instruction.allowed_hosts → новый хост

После правки — снова deployment/scripts/seed.sh (или ручное обновление в БД).

6. Внешние системы

• S3 CORS (Selectel) — Allowed origin: https://новый-домен
• Bitrix24 — URL установки/обработчика (/bitrix/install, /bitrix/handler)
• Keycloak client — redirect URIs / web origins (в realm сейчас зашиты конкретные домены вроде chat.han0107.ru)
• i-Digital — callback URL, если провайдер его фиксирует

Итого: .env + сертификат — ядро, но без DNS, CORS (API + S3), rebuild frontend, Keycloak hostname/redirects, Bitrix URL и seed CORS логин/загрузки/интеграции сломаются.