docs: refactor docs structure
This commit is contained in:
3252a8
@@ -0,0 +1,27 @@
|
||||
# Обслуживание
|
||||
|
||||
Плановое обслуживание обычно сводится к обновлению образов, проверке миграций, логов и резервных копий PostgreSQL.
|
||||
|
||||
## Обновление
|
||||
|
||||
```bash
|
||||
docker compose pull
|
||||
docker compose up -d
|
||||
docker compose logs -f migrate backend worker
|
||||
```
|
||||
|
||||
## Резервная копия PostgreSQL
|
||||
|
||||
```bash
|
||||
docker compose exec -T postgres sh -c 'pg_dump -U "$POSTGRES_USER" -d "$POSTGRES_DB"' > backup.sql
|
||||
```
|
||||
|
||||
## Проверки после работ
|
||||
|
||||
- `docker compose ps`
|
||||
- `docker compose logs -f backend worker frontend`
|
||||
- `/healthz` на backend-домене
|
||||
- вход в Mini App и админку
|
||||
- тестовый платеж или тестовая активация
|
||||
|
||||
Подробности: [развертывание](../deployment.md) и [логи](../troubleshooting/logs.md).
|
||||
@@ -0,0 +1,19 @@
|
||||
# Пользователи
|
||||
|
||||
Пользовательские операции выполняются в Web App админке. Доступ получают только Telegram-пользователи из `ADMIN_IDS`.
|
||||
|
||||
## Что доступно администратору
|
||||
|
||||
- список пользователей с поиском и фильтрами;
|
||||
- просмотр подписки, статуса, трафика и premium-лимитов;
|
||||
- блокировка пользователя;
|
||||
- ручная синхронизация с Remnawave Panel;
|
||||
- тикеты поддержки и ответы пользователю;
|
||||
- просмотр платежей и служебных событий.
|
||||
|
||||
## Связанные разделы
|
||||
|
||||
- [Админ-панель](../features/admin-panel.md)
|
||||
- [Поддержка](../features/support.md)
|
||||
- [Тарифы](../features/tariffs.md)
|
||||
- [Mini App](../features/web-app.md)
|
||||
@@ -7,7 +7,7 @@
|
||||
|
||||
Админка сохраняет overrides в базе данных и применяет их поверх `.env`. Это удобно для платежей, внешнего вида, поддержки, уведомлений, legacy-цен и большинства пользовательских параметров. Тарифы редактируются отдельно в разделе **Система -> Тарифы** и сохраняются в JSON-файл `TARIFFS_CONFIG_PATH`.
|
||||
|
||||
Полный справочник всех переменных вынесен в [env-vars.md](env-vars.md).
|
||||
Полный справочник всех переменных вынесен в [configuration/env-vars.md](configuration/env-vars.md).
|
||||
|
||||
## Минимальный `.env`
|
||||
|
||||
@@ -102,9 +102,9 @@ docker compose exec backend sh -lc 'id; touch /app/data/themes/test && rm /app/d
|
||||
|
||||
## Дополнительные разделы
|
||||
|
||||
- [env-vars.md](env-vars.md) - полный справочник переменных `.env`.
|
||||
- [admin.md](admin.md) - как устроены overrides и allowlist настроек.
|
||||
- [tariffs.md](tariffs.md) - JSON-каталог тарифов и редактор тарифов.
|
||||
- [webapp.md](webapp.md) - домен Mini App, Telegram OAuth и email-вход.
|
||||
- [support.md](support.md) - тикеты поддержки и уведомления.
|
||||
- [configuration/env-vars.md](configuration/env-vars.md) - полный справочник переменных `.env`.
|
||||
- [features/admin-panel.md](features/admin-panel.md) - как устроены overrides и allowlist настроек.
|
||||
- [features/tariffs.md](features/tariffs.md) - JSON-каталог тарифов и редактор тарифов.
|
||||
- [features/web-app.md](features/web-app.md) - домен Mini App, Telegram OAuth и email-вход.
|
||||
- [features/support.md](features/support.md) - тикеты поддержки и уведомления.
|
||||
- [deployment.md](deployment.md) - Docker Compose, reverse proxy, Caddy/Nginx и обновления.
|
||||
|
||||
@@ -368,7 +368,7 @@ PAYMENT_HELEKET_TELEGRAM_EMOJI
|
||||
|
||||
## Поддержка
|
||||
|
||||
Подробный сценарий описан в [support.md](support.md).
|
||||
Подробный сценарий описан в [features/support.md](../features/support.md).
|
||||
|
||||
| Переменная | Назначение |
|
||||
| --- | --- |
|
||||
@@ -0,0 +1,37 @@
|
||||
# Безопасность
|
||||
|
||||
Безопасность Minishop в первую очередь держится на стабильных секретах, корректном разделении публичных доменов и ограниченном доступе к админке.
|
||||
|
||||
## Секреты
|
||||
|
||||
- `WEBAPP_SESSION_SECRET` должен быть постоянным между рестартами, иначе Web App-сессии станут невалидными.
|
||||
- `WEBHOOK_SECRET_TOKEN` защищает Telegram webhook.
|
||||
- `PANEL_WEBHOOK_SECRET` проверяет входящие события Remnawave Panel.
|
||||
- Платежные токены и webhook-секреты храните в `.env` или настройках админки с учетом доступа к серверу.
|
||||
|
||||
Сгенерировать секрет можно так:
|
||||
|
||||
```bash
|
||||
openssl rand -hex 32
|
||||
```
|
||||
|
||||
## Доступ администраторов
|
||||
|
||||
- `ADMIN_IDS` задает Telegram ID администраторов.
|
||||
- Админка доступна только пользователям из `ADMIN_IDS` при входе через Telegram.
|
||||
- Email-only аккаунты не получают админский доступ.
|
||||
|
||||
## Публичные URL
|
||||
|
||||
- `WEBHOOK_BASE_URL` должен вести на backend webhook server.
|
||||
- `SUBSCRIPTION_MINI_APP_URL` должен вести на frontend/Mini App.
|
||||
- Не добавляйте `/api`, `/auth` или webhook-пути в `SUBSCRIPTION_MINI_APP_URL`.
|
||||
|
||||
## Дополнительно
|
||||
|
||||
- Используйте HTTPS на всех публичных доменах.
|
||||
- Ограничивайте доступ к серверу и `.env`.
|
||||
- Следите за логами платежных вебхуков и panel webhooks.
|
||||
- После ротации секретов перезапускайте соответствующие сервисы и проверяйте вебхуки.
|
||||
|
||||
См. также [переменные окружения](env-vars.md) и [развертывание](../deployment.md).
|
||||
@@ -0,0 +1,39 @@
|
||||
# Caddy
|
||||
|
||||
Вариант `deploy/examples/caddy` подходит, если нужен самый простой публичный HTTPS. Caddy сам выпускает и продлевает сертификаты Let's Encrypt.
|
||||
|
||||
## Требования
|
||||
|
||||
- На сервере открыты входящие `80/tcp` и `443/tcp`.
|
||||
- DNS-записи `WEBHOOK_HOST` и `MINIAPP_HOST` смотрят на этот сервер.
|
||||
- В `.env` заполнены домены, токены, секреты и доступы к Remnawave.
|
||||
|
||||
## Запуск
|
||||
|
||||
```bash
|
||||
cd deploy/examples/caddy
|
||||
cp .env.example .env
|
||||
nano .env
|
||||
docker compose up -d
|
||||
```
|
||||
|
||||
Минимально поменяйте:
|
||||
|
||||
- `WEBHOOK_HOST` и `MINIAPP_HOST`;
|
||||
- `BOT_TOKEN`, `ADMIN_IDS`;
|
||||
- `POSTGRES_PASSWORD`;
|
||||
- `WEBAPP_SESSION_SECRET`, `WEBHOOK_SECRET_TOKEN`;
|
||||
- `PANEL_API_URL`, `PANEL_API_KEY`, `PANEL_WEBHOOK_SECRET`.
|
||||
|
||||
## Проверка
|
||||
|
||||
```bash
|
||||
docker compose ps
|
||||
docker compose logs -f caddy backend worker frontend
|
||||
```
|
||||
|
||||
Если нужна нестандартная логика Caddy, правьте `deploy/examples/caddy/Caddyfile` и перезапускайте:
|
||||
|
||||
```bash
|
||||
docker compose up -d --force-recreate caddy
|
||||
```
|
||||
@@ -0,0 +1,39 @@
|
||||
# Deploy examples
|
||||
|
||||
В `deploy/examples` лежат самодостаточные Compose-варианты для разных способов публикации Minishop. Каждый пример запускается из своей директории и содержит собственный `docker-compose.yml`, `.env.example` и README.
|
||||
|
||||
```bash
|
||||
cp .env.example .env
|
||||
nano .env
|
||||
docker compose up -d
|
||||
```
|
||||
|
||||
После старта проверяйте:
|
||||
|
||||
```bash
|
||||
docker compose ps
|
||||
docker compose logs -f backend worker frontend
|
||||
```
|
||||
|
||||
## Какой вариант выбрать
|
||||
|
||||
| Вариант | Когда использовать | Где лежит |
|
||||
| --- | --- | --- |
|
||||
| [Caddy](caddy.md) | Нужен самый простой публичный HTTPS с автоматическими сертификатами Let's Encrypt. | `deploy/examples/caddy` |
|
||||
| [Nginx](nginx.md) | Уже используете Nginx и готовы положить TLS-сертификаты рядом с примером. | `deploy/examples/nginx` |
|
||||
| [Pangolin/Newt](newt.md) | Публикуете сервисы через туннель без входящих портов на сервере приложения. | `deploy/examples/newt` |
|
||||
| [No proxy](no-proxy.md) | Нужно напрямую открыть порты backend/frontend или проверить стек без reverse proxy. | `deploy/examples/no-proxy` |
|
||||
|
||||
## Два публичных URL
|
||||
|
||||
Для production обычно нужны два домена:
|
||||
|
||||
- webhook/backend URL для Telegram, платежных систем и Remnawave webhooks;
|
||||
- Mini App/frontend URL для Telegram Mini App, Web App и админки.
|
||||
|
||||
Пример:
|
||||
|
||||
```text
|
||||
https://webhooks.example.com -> backend:8080
|
||||
https://app.example.com -> frontend:80
|
||||
```
|
||||
@@ -0,0 +1,38 @@
|
||||
# Pangolin / Newt
|
||||
|
||||
Вариант `deploy/examples/newt` подходит, если сервер приложения не должен принимать входящие соединения. Newt подключается к Pangolin, а публичные домены настраиваются ресурсами в панели Pangolin.
|
||||
|
||||
## Запуск
|
||||
|
||||
```bash
|
||||
cd deploy/examples/newt
|
||||
cp .env.example .env
|
||||
nano .env
|
||||
docker compose up -d
|
||||
```
|
||||
|
||||
В `.env` заполните:
|
||||
|
||||
- `WEBHOOK_HOST` и `MINIAPP_HOST` - публичные домены ресурсов в Pangolin;
|
||||
- `PANGOLIN_ENDPOINT`, `NEWT_ID`, `NEWT_SECRET` - значения из настроек site/client в Pangolin;
|
||||
- обычные переменные приложения: `BOT_TOKEN`, `ADMIN_IDS`, `POSTGRES_PASSWORD`, секреты и доступ к Remnawave.
|
||||
|
||||
## Ресурсы Pangolin
|
||||
|
||||
Создайте два HTTP-ресурса для Newt site:
|
||||
|
||||
| Публичный домен | Upstream |
|
||||
| --- | --- |
|
||||
| `https://webhooks.example.com` | `http://backend:8080` |
|
||||
| `https://app.example.com` | `http://frontend:80` |
|
||||
|
||||
Домены в Pangolin должны совпадать с `WEBHOOK_HOST` и `MINIAPP_HOST`.
|
||||
|
||||
Официальная инструкция Pangolin по установке Newt site: <https://docs.pangolin.net/manage/sites/install-site>.
|
||||
|
||||
## Проверка
|
||||
|
||||
```bash
|
||||
docker compose ps
|
||||
docker compose logs -f newt backend worker frontend
|
||||
```
|
||||
@@ -0,0 +1,44 @@
|
||||
# Nginx
|
||||
|
||||
Вариант `deploy/examples/nginx` поднимает Nginx в той же Docker-сети, что и приложение. Он подходит, если у вас уже есть TLS-сертификаты или нужен ручной контроль Nginx-конфига.
|
||||
|
||||
## Маршрутизация
|
||||
|
||||
- `WEBHOOK_HOST` проксируется в `backend:8080`.
|
||||
- `MINIAPP_HOST` проксируется в `frontend:80`.
|
||||
- `frontend` сам проксирует внутренние `/api`, `/auth` и ассеты тем в `backend:8081`.
|
||||
|
||||
## Подготовка
|
||||
|
||||
```bash
|
||||
cd deploy/examples/nginx
|
||||
cp .env.example .env
|
||||
nano .env
|
||||
```
|
||||
|
||||
Положите TLS-сертификаты в `ssl/`:
|
||||
|
||||
```text
|
||||
ssl/
|
||||
webhooks.example.com/
|
||||
fullchain.pem
|
||||
privkey.pem
|
||||
app.example.com/
|
||||
fullchain.pem
|
||||
privkey.pem
|
||||
```
|
||||
|
||||
Имена папок должны совпадать с `WEBHOOK_HOST` и `MINIAPP_HOST` в `.env`.
|
||||
|
||||
## Запуск
|
||||
|
||||
```bash
|
||||
docker compose up -d
|
||||
docker compose logs -f nginx backend worker frontend
|
||||
```
|
||||
|
||||
Если нужно поменять заголовки, лимиты или TLS-настройки, правьте `deploy/examples/nginx/nginx.conf.template` и перезапускайте:
|
||||
|
||||
```bash
|
||||
docker compose up -d --force-recreate nginx
|
||||
```
|
||||
@@ -0,0 +1,35 @@
|
||||
# Без reverse proxy
|
||||
|
||||
Вариант `deploy/examples/no-proxy` напрямую публикует HTTP-порты backend и frontend. Он удобен для локальной проверки, внутренней сети или ситуации, когда HTTPS завершается внешней платформой.
|
||||
|
||||
## Порты
|
||||
|
||||
- backend/webhooks: `WEB_SERVER_BIND`, по умолчанию `0.0.0.0:8080`;
|
||||
- frontend/Mini App: `FRONTEND_BIND`, по умолчанию `0.0.0.0:8082`.
|
||||
|
||||
## Запуск
|
||||
|
||||
```bash
|
||||
cd deploy/examples/no-proxy
|
||||
cp .env.example .env
|
||||
nano .env
|
||||
docker compose up -d
|
||||
```
|
||||
|
||||
## Важно про HTTPS
|
||||
|
||||
Контейнеры приложения сами не выпускают TLS-сертификаты. Для реального Telegram webhook и Mini App публичные URL должны быть HTTPS.
|
||||
|
||||
Используйте этот вариант, если:
|
||||
|
||||
- проверяете стек локально;
|
||||
- публикуете сервисы только во внутренней сети;
|
||||
- TLS уже завершается внешним reverse proxy, load balancer или платформой.
|
||||
|
||||
## Проверка
|
||||
|
||||
```bash
|
||||
curl http://127.0.0.1:8080/healthz
|
||||
curl http://127.0.0.1:8082/health
|
||||
docker compose logs -f backend worker frontend
|
||||
```
|
||||
+13
-13
@@ -1,7 +1,7 @@
|
||||
# Развертывание
|
||||
|
||||
Документ описывает продакшен-запуск после разделения проекта на `backend`, `frontend` и `worker`.
|
||||
Перед стартом заполните минимальный `.env` по [configuration.md](configuration.md). Полный справочник переменных лежит в [env-vars.md](env-vars.md); после первого входа большинство продуктовых настроек удобнее менять через Web App админку.
|
||||
Перед стартом заполните минимальный `.env` по [configuration.md](configuration.md). Полный справочник переменных лежит в [configuration/env-vars.md](configuration/env-vars.md); после первого входа большинство продуктовых настроек удобнее менять через Web App админку.
|
||||
|
||||
## Быстрый старт
|
||||
|
||||
@@ -27,16 +27,16 @@ docker compose logs -f backend worker frontend
|
||||
|
||||
## Готовые папки запуска
|
||||
|
||||
Для production удобнее использовать не корневой compose, а отдельные примеры в
|
||||
[`deploy/examples`](../deploy/examples). В каждой папке лежат свой `docker-compose.yml`,
|
||||
`.env.example`, README и нужный конфиг рядом:
|
||||
Для production удобнее использовать не корневой compose, а отдельные примеры из
|
||||
[Deploy examples](deploy-examples/index.md). В каждой папке лежат свой `docker-compose.yml`,
|
||||
`.env.example` и нужный конфиг рядом, а подробные инструкции хранятся в `docs/`:
|
||||
|
||||
| Папка | Назначение | Запуск |
|
||||
| --- | --- | --- |
|
||||
| [`deploy/examples/caddy`](../deploy/examples/caddy) | Caddy с автоматическим HTTPS. | `cp .env.example .env`, заполнить `.env`, `docker compose up -d`. |
|
||||
| [`deploy/examples/nginx`](../deploy/examples/nginx) | Nginx в Docker-сети приложения, TLS-сертификаты кладутся в `ssl/`. | `cp .env.example .env`, заполнить `.env`, положить сертификаты, `docker compose up -d`. |
|
||||
| [`deploy/examples/newt`](../deploy/examples/newt) | Pangolin/Newt без входящих портов на сервере приложения. | `cp .env.example .env`, заполнить Newt credentials, создать ресурсы в Pangolin, `docker compose up -d`. |
|
||||
| [`deploy/examples/no-proxy`](../deploy/examples/no-proxy) | Прямая публикация портов backend/frontend. | `cp .env.example .env`, заполнить публичные URL и порты, `docker compose up -d`. |
|
||||
| [Caddy](deploy-examples/caddy.md) | Caddy с автоматическим HTTPS. | `cp .env.example .env`, заполнить `.env`, `docker compose up -d`. |
|
||||
| [Nginx](deploy-examples/nginx.md) | Nginx в Docker-сети приложения, TLS-сертификаты кладутся в `ssl/`. | `cp .env.example .env`, заполнить `.env`, положить сертификаты, `docker compose up -d`. |
|
||||
| [Pangolin/Newt](deploy-examples/newt.md) | Pangolin/Newt без входящих портов на сервере приложения. | `cp .env.example .env`, заполнить Newt credentials, создать ресурсы в Pangolin, `docker compose up -d`. |
|
||||
| [No proxy](deploy-examples/no-proxy.md) | Прямая публикация портов backend/frontend. | `cp .env.example .env`, заполнить публичные URL и порты, `docker compose up -d`. |
|
||||
|
||||
Пример для Caddy:
|
||||
|
||||
@@ -84,7 +84,7 @@ docker compose logs migrate
|
||||
- `redis`: Redis 7 для FSM, кеша, rate-limit, очередей и locks.
|
||||
|
||||
В production-примерах внешний доступ добавляют `caddy`, `nginx`, `newt` или прямые `ports` в
|
||||
соответствующей папке из [`deploy/examples`](../deploy/examples).
|
||||
соответствующем варианте из [Deploy examples](deploy-examples/index.md).
|
||||
|
||||
## Логи и проверка
|
||||
|
||||
@@ -246,9 +246,9 @@ docker compose up -d backend worker
|
||||
|
||||
Готовые reverse-proxy примеры лежат в:
|
||||
|
||||
- [`deploy/examples/caddy`](../deploy/examples/caddy) - Caddy, автоматический HTTPS;
|
||||
- [`deploy/examples/nginx`](../deploy/examples/nginx) - Nginx, сертификаты кладутся рядом в `ssl/`;
|
||||
- [`deploy/examples/newt`](../deploy/examples/newt) - Newt/Pangolin, без входящих портов на сервере приложения.
|
||||
- [Caddy](deploy-examples/caddy.md) - автоматический HTTPS;
|
||||
- [Nginx](deploy-examples/nginx.md) - сертификаты кладутся рядом в `ssl/`;
|
||||
- [Newt/Pangolin](deploy-examples/newt.md) - без входящих портов на сервере приложения.
|
||||
|
||||
Во всех вариантах схема одинаковая:
|
||||
|
||||
@@ -274,7 +274,7 @@ app.example.com {
|
||||
|
||||
## Newt
|
||||
|
||||
Для Newt используйте [`deploy/examples/newt`](../deploy/examples/newt). В compose уже есть сервис
|
||||
Для Newt используйте [Pangolin / Newt](deploy-examples/newt.md). В compose уже есть сервис
|
||||
`newt`, а в `.env.example` - поля `PANGOLIN_ENDPOINT`, `NEWT_ID` и `NEWT_SECRET`.
|
||||
|
||||
В Pangolin создайте два HTTP-ресурса для этого Newt site:
|
||||
|
||||
@@ -0,0 +1,22 @@
|
||||
# Основные возможности
|
||||
|
||||
Minishop закрывает путь от регистрации пользователя до оплаты, продления, поддержки и сопровождения подписки.
|
||||
|
||||
## Для пользователей
|
||||
|
||||
- Регистрация через Telegram Mini App или email-код.
|
||||
- Просмотр подписки, срока действия, трафика и ссылки подключения.
|
||||
- Покупка подписки, пакетов трафика и дополнительных устройств.
|
||||
- Пробный период, промокоды и реферальные сценарии.
|
||||
- Тикеты поддержки внутри Mini App.
|
||||
- Встроенные инструкции установки и публичные ссылки `/s/<token>`.
|
||||
|
||||
## Для администраторов
|
||||
|
||||
- Поиск и управление пользователями.
|
||||
- Настройка платежей, тарифов, внешнего вида и поддержки.
|
||||
- Рассылки, промокоды и логи действий.
|
||||
- Ручная синхронизация с Remnawave Panel.
|
||||
- Редактор JSON-каталога тарифов.
|
||||
|
||||
Подробности: [админ-панель](admin-panel.md), [Mini App](web-app.md) и [поддержка](support.md).
|
||||
@@ -0,0 +1,28 @@
|
||||
# Платежи
|
||||
|
||||
Платежные методы включаются настройками и отображаются пользователю как кнопки оплаты в Mini App и Telegram-сценариях.
|
||||
|
||||
## Поддерживаемые провайдеры
|
||||
|
||||
- [YooKassa](../payments/yookassa.md)
|
||||
- [FreeKassa](../payments/freekassa.md)
|
||||
- [Platega](../payments/platega.md)
|
||||
- [SeverPay](../payments/severpay.md)
|
||||
- [Wata](../payments/wata.md)
|
||||
- [CryptoPay](../payments/cryptopay.md)
|
||||
- [Heleket](../payments/heleket.md)
|
||||
- [Telegram Stars](../payments/telegram-stars.md)
|
||||
|
||||
## Типовой порядок настройки
|
||||
|
||||
1. Включите нужный провайдер в админке или через `.env`.
|
||||
2. Заполните публичные параметры и секреты.
|
||||
3. Настройте webhook URL у провайдера, если это требуется.
|
||||
4. Проверьте порядок и подписи кнопок оплаты.
|
||||
5. Выполните тестовый платеж и проверьте логи backend.
|
||||
|
||||
## Где смотреть параметры
|
||||
|
||||
- [Справочник `.env`](../configuration/env-vars.md) содержит все ключи провайдеров.
|
||||
- [Админ-панель](admin-panel.md) описывает UI-настройки платежей.
|
||||
- [Тарифы](tariffs.md) описывают цены, Stars и сценарии покупки.
|
||||
@@ -0,0 +1,21 @@
|
||||
# Подписки
|
||||
|
||||
Подписки управляются через каталог тарифов и синхронизируются с Remnawave Panel.
|
||||
|
||||
## Модели тарифов
|
||||
|
||||
- **Period** - подписка на срок с месячным лимитом трафика.
|
||||
- **Traffic** - покупка пакетов трафика без привязки к периоду.
|
||||
- **Premium** - отдельные premium-сквады и premium-лимит.
|
||||
- **HWID-устройства** - докупка дополнительных устройств при включенном разделе устройств.
|
||||
|
||||
## Жизненный цикл
|
||||
|
||||
- создание пользователя в панели;
|
||||
- применение пробного периода или покупки;
|
||||
- продление и докупки;
|
||||
- предупреждения по трафику;
|
||||
- синхронизация подписки и статусов;
|
||||
- обработка смены тарифа.
|
||||
|
||||
Подробности: [тарифы](tariffs.md) и [Mini App](web-app.md).
|
||||
@@ -64,7 +64,7 @@ Email-уведомления администраторам включаются
|
||||
| `SUPPORT_ADMIN_NOTIFICATION_COOLDOWN_SECONDS` | Минимальная пауза между повторными Telegram/log уведомлениями по одному непрочитанному тикету. |
|
||||
| `SUPPORT_ADMIN_EMAIL_COOLDOWN_SECONDS` | Минимальная пауза между повторными email-уведомлениями по одному непрочитанному тикету. |
|
||||
|
||||
Все эти параметры описаны в [env-vars.md](env-vars.md). Основной рекомендуемый способ менять их - админка **Система -> Настройки -> Поддержка**; значения применяются как override поверх `.env`.
|
||||
Все эти параметры описаны в [env-vars.md](../configuration/env-vars.md). Основной рекомендуемый способ менять их - админка **Система -> Настройки -> Поддержка**; значения применяются как override поверх `.env`.
|
||||
|
||||
## API и хранение
|
||||
|
||||
@@ -5,7 +5,7 @@
|
||||
- JSON-каталог тарифов из `TARIFFS_CONFIG_PATH` (по умолчанию `data/tariffs.json`);
|
||||
- конфигурация через переменные `.env`, если JSON-файл отсутствует.
|
||||
|
||||
JSON-каталог может содержать несколько тарифов разных моделей: подписки на срок, пакеты трафика без срока действия, разные наборы Internal Squads, лимиты устройств и пакеты докупки. Пример формата: [data/tariffs.example.json](../data/tariffs.example.json).
|
||||
JSON-каталог может содержать несколько тарифов разных моделей: подписки на срок, пакеты трафика без срока действия, разные наборы Internal Squads, лимиты устройств и пакеты докупки. Пример формата: [data/tariffs.example.json](https://gitlab.com/3252a8/remnawave-minshop/-/blob/main/data/tariffs.example.json).
|
||||
|
||||
Коротко по моделям:
|
||||
|
||||
@@ -30,7 +30,7 @@ JSON-каталог может содержать несколько тариф
|
||||
|
||||
После сохранения изменения применяются к новым запросам Web App сразу, потому что конфиг тарифов загружается из JSON при обращении. Уже созданные подписки сохраняют свой `tariff_key`; при удалении или отключении тарифа проверьте, что активные подписки с этим ключом не требуют дальнейшего продления или смены.
|
||||
|
||||
Подробности по админ-панели, правам доступа, сохранению настроек и списку разделов есть в [admin.md](admin.md).
|
||||
Подробности по админ-панели, правам доступа, сохранению настроек и списку разделов есть в [админ-панели](admin-panel.md).
|
||||
|
||||
## Как выбирается режим
|
||||
|
||||
@@ -16,7 +16,7 @@ Web App собирается в отдельный `frontend` image и отда
|
||||
- реферальную ссылку и статистику приглашений;
|
||||
- привязку email и Telegram к одному аккаунту.
|
||||
|
||||
Для администраторов из `ADMIN_IDS` Web App также показывает админ-панель: статистику, **пользователей** (поиск, фильтры, premium-трафик), поддержку, рассылки, промокоды, логи, настройки и редактор тарифов. Подробности: [admin.md](admin.md).
|
||||
Для администраторов из `ADMIN_IDS` Web App также показывает админ-панель: статистику, **пользователей** (поиск, фильтры, premium-трафик), поддержку, рассылки, промокоды, логи, настройки и редактор тарифов. Подробности: [админ-панель](admin-panel.md).
|
||||
|
||||
## Настройки `.env`
|
||||
|
||||
@@ -118,7 +118,7 @@ Email-вход работает через одноразовый код:
|
||||
|
||||
Для Brevo обычно подходит порт `587` с STARTTLS. Если основной порт недоступен, приложение пробует порты из `SMTP_FALLBACK_PORTS`; порт `465` используется через SSL.
|
||||
|
||||
Полный список переменных, обязательные поля для включения email-входа и типичные ошибки подключения описаны в разделе **SMTP и вход по email** в [configuration.md](configuration.md).
|
||||
Полный список переменных, обязательные поля для включения email-входа и типичные ошибки подключения описаны в разделе **SMTP и вход по email** в [configuration.md](../configuration.md).
|
||||
|
||||
## Проксирование
|
||||
|
||||
@@ -131,12 +131,12 @@ Email-вход работает через одноразовый код:
|
||||
WebApp API на `backend:8081`, поэтому внешний reverse proxy обычно не должен отправлять эти пути в
|
||||
`backend:8081` напрямую.
|
||||
|
||||
Готовые примеры лежат в [`deploy/examples`](../deploy/examples):
|
||||
Готовые варианты описаны в [Deploy examples](../deploy-examples/index.md):
|
||||
|
||||
- `caddy` - Caddy с автоматическим HTTPS;
|
||||
- `nginx` - Nginx с сертификатами в соседней папке `ssl/`;
|
||||
- `newt` - Pangolin/Newt;
|
||||
- `no-proxy` - прямая публикация портов для проверки или внешней TLS-платформы.
|
||||
- [Caddy](../deploy-examples/caddy.md) - автоматический HTTPS;
|
||||
- [Nginx](../deploy-examples/nginx.md) - сертификаты в соседней папке `ssl/`;
|
||||
- [Pangolin/Newt](../deploy-examples/newt.md) - публикация без входящих портов на сервере приложения;
|
||||
- [No proxy](../deploy-examples/no-proxy.md) - прямая публикация портов для проверки или внешней TLS-платформы.
|
||||
|
||||
В default `docker-compose.yml` наружу публикуются `frontend` и webhook/backend port, а внутри Docker
|
||||
network сервисы доступны друг другу по service DNS names:
|
||||
|
Before Width: | Height: | Size: 105 KiB After Width: | Height: | Size: 105 KiB |
@@ -0,0 +1,26 @@
|
||||
# Обзор
|
||||
|
||||
Remnawave Minishop состоит из Telegram-бота, backend API, worker-процессов, frontend/Mini App и инфраструктурных сервисов PostgreSQL и Redis. В production эти части запускаются через Docker Compose и общаются с Remnawave Panel по API и вебхукам.
|
||||
|
||||
## Основные компоненты
|
||||
|
||||
- **Backend** - Telegram webhook, платежные вебхуки, panel webhooks, API для Mini App и админки.
|
||||
- **Worker** - фоновые задачи, синхронизация подписок, обработка очереди вебхуков и тарифных событий.
|
||||
- **Frontend** - отдельный nginx-образ с Mini App и админкой.
|
||||
- **PostgreSQL** - пользователи, платежи, настройки, поддержка, промокоды и служебные данные.
|
||||
- **Redis** - FSM, кеши, rate limit, очередь вебхуков и distributed locks.
|
||||
|
||||
## Сценарии
|
||||
|
||||
- пользователь открывает Mini App, видит подписку и оплачивает тариф;
|
||||
- платежный провайдер отправляет webhook в backend;
|
||||
- worker применяет фоновые задачи и синхронизацию;
|
||||
- Remnawave Panel хранит пользователя, подписку и ссылку подключения;
|
||||
- администратор управляет тарифами, поддержкой, пользователями и настройками через админку.
|
||||
|
||||
## Куда идти дальше
|
||||
|
||||
- [Установка](setup.md) - базовый запуск через Compose.
|
||||
- [Deploy examples](../deploy-examples/index.md) - готовые варианты публикации.
|
||||
- [Архитектура](../architecture.md) - структура каталогов и сервисов.
|
||||
- [Mini App](../features/web-app.md) - публичный frontend, Telegram OAuth и инструкции установки.
|
||||
@@ -0,0 +1,38 @@
|
||||
# Установка
|
||||
|
||||
Начните с `.env`, затем поднимите Compose-стек и проверьте backend, worker и frontend.
|
||||
|
||||
## Минимальный запуск
|
||||
|
||||
```bash
|
||||
cp .env.example .env
|
||||
nano .env
|
||||
docker compose up -d --build
|
||||
docker compose ps
|
||||
docker compose logs -f backend worker frontend
|
||||
```
|
||||
|
||||
## Что заполнить в первую очередь
|
||||
|
||||
- `BOT_TOKEN` и `ADMIN_IDS` для доступа к боту и админке.
|
||||
- `WEBHOOK_BASE_URL` для Telegram, платежных и panel webhook URL.
|
||||
- `SUBSCRIPTION_MINI_APP_URL` для Mini App и кнопок в Telegram.
|
||||
- `POSTGRES_USER`, `POSTGRES_PASSWORD`, `POSTGRES_DB`.
|
||||
- `WEBAPP_SESSION_SECRET`, `WEBHOOK_SECRET_TOKEN`, `PANEL_API_URL`, `PANEL_API_KEY`, `PANEL_WEBHOOK_SECRET`.
|
||||
|
||||
## Как выбрать Compose-вариант
|
||||
|
||||
- Для быстрого публичного HTTPS берите [Caddy](../deploy-examples/caddy.md).
|
||||
- Если у вас уже есть TLS-сертификаты и нужен Nginx в Docker-сети, берите [Nginx](../deploy-examples/nginx.md).
|
||||
- Если нельзя открывать входящие порты на сервере приложения, берите [Pangolin/Newt](../deploy-examples/newt.md).
|
||||
- Для локальной проверки или внешнего TLS-терминатора берите [no-proxy](../deploy-examples/no-proxy.md).
|
||||
|
||||
## После первого входа
|
||||
|
||||
1. Откройте админку через Mini App.
|
||||
2. Проверьте платежные методы в настройках.
|
||||
3. Настройте каталог тарифов.
|
||||
4. Проверьте инструкции подключения.
|
||||
5. Сделайте тестовую покупку или пробную активацию.
|
||||
|
||||
Подробности: [настройка окружения](../configuration.md) и [развертывание](../deployment.md).
|
||||
@@ -0,0 +1,32 @@
|
||||
# Remnawave Minishop
|
||||
|
||||
Remnawave Minishop - Telegram-бот и Mini App для продажи и управления подписками Remnawave. Документация помогает развернуть стек, настроить платежи, тарифы, админку, поддержку и публичный личный кабинет.
|
||||
|
||||
> Проект работает вместе с Remnawave Panel: панель хранит пользователей и подписки, а Minishop отвечает за Telegram, платежи, Mini App, тарифы и операционную админку.
|
||||
|
||||
## Быстрый старт
|
||||
|
||||
- [Обзор](getting-started/overview.md) - архитектура, сервисы и основные сценарии.
|
||||
- [Установка](getting-started/setup.md) - путь от `.env` до первого запуска.
|
||||
- [Deploy examples](deploy-examples/index.md) - Caddy, Nginx, Pangolin/Newt и no-proxy варианты.
|
||||
- [Настройка платежей](features/payments.md) - включение провайдеров и проверка вебхуков.
|
||||
- [Безопасность](configuration/security.md) - секреты, доступы и публичные URL.
|
||||
- [Админ-панель](features/admin-panel.md) - пользователи, настройки, рассылки, поддержка и тарифы.
|
||||
- [Миграции](migrations/index.md) - готовые сценарии переноса с других ботов.
|
||||
- [Устранение неполадок](troubleshooting/issues.md) - быстрые проверки для частых проблем.
|
||||
|
||||
## Ключевые возможности
|
||||
|
||||
- **Продажа подписок** - period- и traffic-тарифы, докупки трафика, HWID-устройства, premium-сквады и Telegram Stars.
|
||||
- **Жизненный цикл пользователей** - регистрация, пробный период, продление, синхронизация с панелью и предупреждения по трафику.
|
||||
- **Mini App** - личный кабинет, инструкции установки, Telegram OAuth, email-вход и публичные referral-ссылки.
|
||||
- **Операционные инструменты** - админка, тикеты поддержки, промокоды, рассылки, логи и настройки поверх `.env`.
|
||||
|
||||
## Справочник
|
||||
|
||||
- [Переменные окружения](configuration/env-vars.md)
|
||||
- [Развертывание](deployment.md)
|
||||
- [Тарифы](features/tariffs.md)
|
||||
- [Темы Web App](features/webapp-themes.md)
|
||||
- [Миграции](migrations/index.md)
|
||||
- [Миграция с remnawave-tg-shop](migrations/remnawave-tg-shop.md)
|
||||
@@ -0,0 +1,27 @@
|
||||
# Миграции с других ботов
|
||||
|
||||
Этот раздел содержит готовые инструкции миграции в Remnawave Minishop из уже описанных источников. Каждая поддерживаемая миграция должна быть отдельным Markdown-файлом с конкретными шагами, ограничениями, командами и проверками.
|
||||
|
||||
Сейчас в документации есть только один готовый сценарий:
|
||||
|
||||
| Источник | Поддерживаемый случай | Инструкция |
|
||||
| --- | --- | --- |
|
||||
| `remnawave-tg-shop` `v2.7.0` и близкие версии | Переезд старого stack/volume PostgreSQL на split-архитектуру Minishop `v3.4+`, обновление `.env`, запуск `migrate`, проверка reverse proxy | [Миграция с remnawave-tg-shop](remnawave-tg-shop.md) |
|
||||
|
||||
## Что покрывает текущая миграция
|
||||
|
||||
Инструкция для `remnawave-tg-shop` рассчитана на родственный стек, где заранее известны Docker volumes, контейнеры, схема БД и путь обновления:
|
||||
|
||||
- перенос PostgreSQL volume `remnawave-tg-shop-db-data` в новый volume Minishop;
|
||||
- создание новых пустых volumes `redis-data` и `shop-data`;
|
||||
- перенос Caddy volumes при использовании Caddy-варианта;
|
||||
- обновление переменных окружения, которые изменились после `v2.7.0`;
|
||||
- запуск one-shot сервиса `migrate`;
|
||||
- переход с одного upstream `remnawave-tg-shop:8000` на `backend:8080` и `frontend:80`;
|
||||
- запуск через корневой compose или готовые deploy examples.
|
||||
|
||||
## Что пока не описано
|
||||
|
||||
Для других Telegram-ботов, самописных панелей и ручных таблиц готовой инструкции пока нет. Такие источники нельзя переносить по инструкции `remnawave-tg-shop`: у них могут отличаться таблицы пользователей, модель тарифов, статусы платежей, связь с Remnawave Panel, формат промокодов, рефералы и правила отката.
|
||||
|
||||
Когда для конкретного источника появится проверенный сценарий, он должен быть добавлен в этот раздел отдельным файлом и отдельной строкой в таблице выше.
|
||||
@@ -1,5 +1,9 @@
|
||||
# Миграция с `remnawave-tg-shop` (≤ v2.7.0) на `remnawave-minishop` (v3.4+)
|
||||
|
||||
Эта страница - готовый сценарий для legacy-стека `remnawave-tg-shop`. Это единственная миграция с другого бота, которая сейчас описана в документации. Для других Telegram-ботов, самописных панелей и ручных таблиц готового сценария пока нет: их нельзя переносить по этой инструкции без отдельного анализа схемы БД, тарифов, платежей и связи с Remnawave Panel.
|
||||
|
||||
Автоматический скрипт ниже рассчитан именно на родственный стек `remnawave-tg-shop`, где структура БД и Docker volumes известны заранее. Для других ботов нужен отдельный адаптер экспорта/импорта.
|
||||
|
||||
## Короткий путь без смены ветки и сборки
|
||||
|
||||
Если вы используете только готовые Docker-образы и не собираете проект
|
||||
@@ -127,7 +131,7 @@ docker compose \
|
||||
| — | `REDIS_URL=redis://redis:6379/0` | Обязательна для воркера, очередей и rate-limit. По умолчанию в compose-файлах уже задана. |
|
||||
| — | `WEBAPP_SESSION_SECRET`, `WEBAPP_ENABLED`, `WEBAPP_SERVER_PORT`, `WEBAPP_THEMES_DIR`, `TARIFFS_CONFIG_PATH` | Новые настройки Web App / тарифного каталога. Безопасные дефолты есть в `.env.example`. |
|
||||
|
||||
Полный референс — [docs/configuration.md](configuration.md). Скрипт миграции
|
||||
Полный референс — [docs/configuration.md](../configuration.md). Скрипт миграции
|
||||
эти переменные **не правит** автоматически (только `POSTGRES_HOST`), потому
|
||||
что у каждой инсталляции свой шаблон `.env` с кастомными значениями. Лучше
|
||||
сравнить свой `.env` с `.env.example` глазами один раз, чем получить
|
||||
@@ -357,8 +361,8 @@ server {
|
||||
```
|
||||
|
||||
Полные примеры (Caddy, Nginx, Newt/Pangolin и запуск без reverse proxy) — в
|
||||
[docs/deployment.md](deployment.md), [docs/webapp.md](webapp.md) и папке
|
||||
[`deploy/examples`](../deploy/examples). Если раньше прокси указывал на
|
||||
[docs/deployment.md](../deployment.md), [docs/features/web-app.md](../features/web-app.md) и
|
||||
[Deploy examples](../deploy-examples/index.md). Если раньше прокси указывал на
|
||||
`remnawave-tg-shop:8000` напрямую, после миграции нужно либо переключиться на
|
||||
`backend:8080` / `frontend:80`, либо использовать готовый Caddy/Nginx/Newt
|
||||
пример, который уже знает правильную маршрутизацию.
|
||||
@@ -0,0 +1,28 @@
|
||||
# CryptoPay
|
||||
|
||||
CryptoPay используется для криптовалютных платежей через отдельный токен и сеть Crypto Bot API.
|
||||
|
||||
## Что включить
|
||||
|
||||
- `CRYPTOPAY_ENABLED` - включает CryptoPay среди доступных методов.
|
||||
- Presentation-ключи `PAYMENT_CRYPTOPAY_*` - подписи и иконки кнопки в Mini App и Telegram.
|
||||
|
||||
## Что настроить
|
||||
|
||||
1. Укажите `CRYPTOPAY_TOKEN`.
|
||||
2. Выберите `CRYPTOPAY_NETWORK`: `mainnet` или `testnet`.
|
||||
3. Задайте `CRYPTOPAY_CURRENCY_TYPE`: `fiat` или `crypto`.
|
||||
4. Проверьте `CRYPTOPAY_ASSET`, например `RUB`, `USDT` или `BTC`.
|
||||
5. Добавьте `cryptopay` в `PAYMENT_METHODS_ORDER`.
|
||||
|
||||
## Проверка
|
||||
|
||||
- Для тестов используйте соответствующую сеть: testnet-токен не должен попадать в mainnet-настройки.
|
||||
- Выполните тестовый платеж и проверьте, что статус закрывается после callback от провайдера.
|
||||
- Если сумма или asset выглядят неверно, проверьте сочетание `CRYPTOPAY_CURRENCY_TYPE` и `CRYPTOPAY_ASSET`.
|
||||
|
||||
## Где подробнее
|
||||
|
||||
- [Переменные CryptoPay](../configuration/env-vars.md#cryptopay)
|
||||
- [Настройка платежей](../features/payments.md)
|
||||
- [Логи и диагностика](../troubleshooting/logs.md)
|
||||
@@ -0,0 +1,16 @@
|
||||
# FreeKassa
|
||||
|
||||
FreeKassa подключается как отдельный платежный метод и обрабатывает входящие webhook-события через backend.
|
||||
|
||||
## Что настроить
|
||||
|
||||
- Включение провайдера: `FREEKASSA_ENABLED`.
|
||||
- ID магазина, API/secret-ключи и настройки подписи.
|
||||
- Trusted IP allowlist, если используется.
|
||||
- Публичный webhook URL на `WEBHOOK_BASE_URL`.
|
||||
|
||||
## Где подробнее
|
||||
|
||||
- [Переменные FreeKassa](../configuration/env-vars.md#freekassa)
|
||||
- [Платежи](../features/payments.md)
|
||||
- [Логи и проверка](../troubleshooting/logs.md)
|
||||
@@ -0,0 +1,31 @@
|
||||
# Heleket
|
||||
|
||||
Heleket используется для crypto-инвойсов с отдельными merchant ID, payment API key, валютой инвойса и настройками webhook-проверки.
|
||||
|
||||
## Что включить
|
||||
|
||||
- `HELEKET_ENABLED` - включает Heleket среди доступных методов.
|
||||
- Presentation-ключи `PAYMENT_HELEKET_*` - подписи и иконки кнопки.
|
||||
|
||||
## Что настроить
|
||||
|
||||
1. Укажите `HELEKET_BASE_URL`, `HELEKET_MERCHANT_ID` и `HELEKET_API_KEY`.
|
||||
2. Настройте `HELEKET_CURRENCY`.
|
||||
3. При необходимости задайте `HELEKET_TO_CURRENCY` и `HELEKET_NETWORK`.
|
||||
4. Проверьте `HELEKET_RETURN_URL` и `HELEKET_SUCCESS_URL`.
|
||||
5. Настройте `HELEKET_LIFETIME_SECONDS`: допустимый диапазон 300..43200.
|
||||
6. Если включаете проверку webhook, задайте `HELEKET_VERIFY_WEBHOOK_SIGNATURE`.
|
||||
7. Для IP-фильтрации заполните `HELEKET_TRUSTED_IPS`.
|
||||
8. Добавьте `heleket` в `PAYMENT_METHODS_ORDER`.
|
||||
|
||||
## Проверка
|
||||
|
||||
- Создайте тестовый инвойс и убедитесь, что пользователь получает корректную ссылку.
|
||||
- Проверьте, что сеть и валюта соответствуют настройкам в кабинете Heleket.
|
||||
- Если webhook отклоняется, проверьте подпись, allowlist и фактический payload в backend-логах.
|
||||
|
||||
## Где подробнее
|
||||
|
||||
- [Переменные Heleket](../configuration/env-vars.md#heleket)
|
||||
- [Настройка платежей](../features/payments.md)
|
||||
- [Логи и диагностика](../troubleshooting/logs.md)
|
||||
@@ -0,0 +1,30 @@
|
||||
# Platega
|
||||
|
||||
Platega подключается как отдельный платежный провайдер, но внутри Minishop может дать несколько кнопок: основную legacy-кнопку, СБП/карту и крипто-кнопку. Общие merchant-параметры задаются один раз, а method ID и подписи кнопок настраиваются отдельно.
|
||||
|
||||
## Что включить
|
||||
|
||||
- `PLATEGA_ENABLED` - общий флаг провайдера.
|
||||
- `PLATEGA_SBP_ENABLED` - отдельная кнопка СБП/карта.
|
||||
- `PLATEGA_CRYPTO_ENABLED` - отдельная crypto-кнопка Platega.
|
||||
- `PLATEGA_PAYMENT_METHOD` - legacy/fallback method ID для старых callback и старых установок.
|
||||
|
||||
## Что настроить
|
||||
|
||||
1. Укажите `PLATEGA_BASE_URL`, `PLATEGA_MERCHANT_ID` и `PLATEGA_SECRET`.
|
||||
2. Заполните `PLATEGA_SBP_METHOD` и/или `PLATEGA_CRYPTO_METHOD`, если используете отдельные кнопки.
|
||||
3. Проверьте `PLATEGA_RETURN_URL` и `PLATEGA_FAILED_URL`.
|
||||
4. Настройте тексты и иконки кнопок через `PAYMENT_PLATEGA_SBP_*` и `PAYMENT_PLATEGA_CRYPTO_*`.
|
||||
5. Добавьте нужные методы в `PAYMENT_METHODS_ORDER`.
|
||||
|
||||
## Проверка
|
||||
|
||||
- После сохранения настроек откройте Mini App и убедитесь, что видны только включенные Platega-кнопки.
|
||||
- Выполните тестовую оплату для каждой включенной кнопки: СБП/карта и crypto используют разные method ID.
|
||||
- При ошибках проверьте backend-логи и ответ провайдера при создании платежной ссылки.
|
||||
|
||||
## Где подробнее
|
||||
|
||||
- [Переменные Platega](../configuration/env-vars.md#platega)
|
||||
- [Настройка платежей](../features/payments.md)
|
||||
- [Логи и диагностика](../troubleshooting/logs.md)
|
||||
@@ -0,0 +1,28 @@
|
||||
# SeverPay
|
||||
|
||||
SeverPay подключается как отдельный платежный метод с собственным MID, token и сроком жизни платежной ссылки.
|
||||
|
||||
## Что включить
|
||||
|
||||
- `SEVERPAY_ENABLED` - показывает SeverPay среди доступных методов оплаты.
|
||||
- Presentation-ключи `PAYMENT_SEVERPAY_*` - подписи и иконки кнопки в Mini App и Telegram.
|
||||
|
||||
## Что настроить
|
||||
|
||||
1. Укажите `SEVERPAY_BASE_URL`.
|
||||
2. Заполните `SEVERPAY_MID` и `SEVERPAY_TOKEN`.
|
||||
3. Настройте `SEVERPAY_RETURN_URL`.
|
||||
4. При необходимости задайте `SEVERPAY_LIFETIME_MINUTES`.
|
||||
5. Добавьте `severpay` в `PAYMENT_METHODS_ORDER`.
|
||||
|
||||
## Проверка
|
||||
|
||||
- Создайте тестовый платеж и проверьте, что пользователь получает платежную ссылку.
|
||||
- Убедитесь, что ссылка живет ожидаемое время, если задан `SEVERPAY_LIFETIME_MINUTES`.
|
||||
- После оплаты проверьте статус платежа в backend-логах и в админке.
|
||||
|
||||
## Где подробнее
|
||||
|
||||
- [Переменные SeverPay](../configuration/env-vars.md#severpay)
|
||||
- [Настройка платежей](../features/payments.md)
|
||||
- [Логи и диагностика](../troubleshooting/logs.md)
|
||||
@@ -0,0 +1,19 @@
|
||||
# Telegram Stars
|
||||
|
||||
Telegram Stars используются напрямую и поддерживаются в legacy-ценах и JSON-каталоге тарифов.
|
||||
|
||||
## Где применяются Stars
|
||||
|
||||
- Цены периодов подписки.
|
||||
- Пакеты трафика.
|
||||
- Premium-докупки.
|
||||
- HWID-докупки, если они включены в каталоге тарифов.
|
||||
|
||||
## Что проверить
|
||||
|
||||
- `STARS_ENABLED`.
|
||||
- Stars-цены в legacy-настройках или JSON-каталоге.
|
||||
- Корректное округление цены до целого количества Stars.
|
||||
- Сценарии смены тарифа: XTR/Stars-докупки не конвертируются без явного курса.
|
||||
|
||||
Подробности: [переменные платежей](../configuration/env-vars.md#платежи) и [тарифы](../features/tariffs.md).
|
||||
@@ -0,0 +1,30 @@
|
||||
# Wata
|
||||
|
||||
Wata подключается как отдельный провайдер с bearer token, платежными ссылками и опциональной проверкой подписи webhook.
|
||||
|
||||
## Что включить
|
||||
|
||||
- `WATA_ENABLED` - включает Wata для пользователей.
|
||||
- `WATA_ADMIN_ONLY_ENABLED` - оставляет метод доступным только для админских сценариев, если используется вместо публичного включения.
|
||||
- Presentation-ключи `PAYMENT_WATA_*` - подписи и иконки кнопки.
|
||||
|
||||
## Что настроить
|
||||
|
||||
1. Укажите `WATA_BASE_URL` и `WATA_API_TOKEN`.
|
||||
2. Проверьте `WATA_RETURN_URL` и `WATA_FAILED_URL`.
|
||||
3. Настройте `WATA_LINK_TTL_MINUTES`: минимум 15 минут, максимум 43200.
|
||||
4. Если включаете проверку подписи, задайте `WATA_WEBHOOK_VERIFY_SIGNATURE` и при необходимости `WATA_PUBLIC_KEY`.
|
||||
5. Для дополнительной защиты заполните `WATA_TRUSTED_IPS`.
|
||||
6. Добавьте `wata` в `PAYMENT_METHODS_ORDER`.
|
||||
|
||||
## Проверка
|
||||
|
||||
- Создайте тестовый платеж и убедитесь, что ссылка открывается у пользователя.
|
||||
- Проверьте входящий webhook: подпись и IP-allowlist должны соответствовать фактическому запросу Wata.
|
||||
- Если платеж остается в pending, проверьте backend-логи вокруг webhook и статуса ссылки.
|
||||
|
||||
## Где подробнее
|
||||
|
||||
- [Переменные Wata](../configuration/env-vars.md#wata)
|
||||
- [Настройка платежей](../features/payments.md)
|
||||
- [Логи и диагностика](../troubleshooting/logs.md)
|
||||
@@ -0,0 +1,16 @@
|
||||
# YooKassa
|
||||
|
||||
YooKassa используется для рублевых оплат и может участвовать в сценариях автопродления period-подписок.
|
||||
|
||||
## Что настроить
|
||||
|
||||
- Включение провайдера: `YOOKASSA_ENABLED`.
|
||||
- Идентификаторы и секреты магазина.
|
||||
- Webhook URL на backend-домен.
|
||||
- Отображение кнопки оплаты и порядок платежных методов.
|
||||
|
||||
## Где подробнее
|
||||
|
||||
- [Переменные YooKassa](../configuration/env-vars.md#yookassa)
|
||||
- [Платежи](../features/payments.md)
|
||||
- [Тарифы и автопродление](../features/tariffs.md#автопродление-пробный-период-и-бонусы)
|
||||
@@ -0,0 +1,33 @@
|
||||
# Проблемы
|
||||
|
||||
Начинайте диагностику с состояния контейнеров и логов, затем проверяйте публичные URL и секреты.
|
||||
|
||||
## Стек не стартует
|
||||
|
||||
- Проверьте `docker compose ps`.
|
||||
- Посмотрите `docker compose logs migrate`.
|
||||
- Убедитесь, что PostgreSQL и Redis здоровы.
|
||||
- Проверьте обязательные переменные в `.env`.
|
||||
|
||||
## Telegram webhook не работает
|
||||
|
||||
- Проверьте `WEBHOOK_BASE_URL`.
|
||||
- Убедитесь, что домен доступен по HTTPS.
|
||||
- Проверьте `WEBHOOK_SECRET_TOKEN`.
|
||||
- Посмотрите backend-логи на момент входящего события.
|
||||
|
||||
## Mini App не открывается
|
||||
|
||||
- Проверьте `SUBSCRIPTION_MINI_APP_URL`.
|
||||
- Убедитесь, что URL указывает на frontend, а не на `/api` или webhook-домен.
|
||||
- Проверьте настройки BotFather.
|
||||
- Посмотрите frontend и backend-логи.
|
||||
|
||||
## Платеж не засчитался
|
||||
|
||||
- Проверьте включение провайдера.
|
||||
- Проверьте webhook URL и секреты.
|
||||
- Посмотрите backend-логи.
|
||||
- Сверьте статус платежа в админке и кабинете провайдера.
|
||||
|
||||
Подробности: [логи](logs.md) и [развертывание](../deployment.md).
|
||||
@@ -0,0 +1,104 @@
|
||||
# Логи
|
||||
|
||||
Логи - главный источник диагностики при проблемах запуска, платежей, вебхуков и синхронизации с Remnawave Panel.
|
||||
|
||||
## Основные команды
|
||||
|
||||
```bash
|
||||
docker compose logs -f backend
|
||||
docker compose logs -f worker
|
||||
docker compose logs -f frontend
|
||||
docker compose logs migrate
|
||||
```
|
||||
|
||||
## Что искать
|
||||
|
||||
- ошибки миграций в `migrate`;
|
||||
- ошибки Telegram webhook и payment webhook в `backend`;
|
||||
- проблемы очереди вебхуков и фоновых задач в `worker`;
|
||||
- ошибки проксирования `/api`, `/auth` и theme assets во `frontend`;
|
||||
- ошибки авторизации Mini App и Telegram OAuth.
|
||||
|
||||
## Frontend proxy, `/api`, `/auth` и theme assets
|
||||
|
||||
`frontend` - это nginx-контейнер Mini App. Он отдает статику и проксирует Web App маршруты во внутренний backend WebApp server на `backend:8081`.
|
||||
|
||||
Сначала смотрите nginx-логи:
|
||||
|
||||
```bash
|
||||
docker compose logs -f frontend
|
||||
```
|
||||
|
||||
Если видите `404`, `502`, `upstream` или `connect() failed`, проверьте маршруты:
|
||||
|
||||
- `/api/*` и `/auth/*` должны попадать в `frontend:80`, а уже frontend проксирует их в `backend:8081`;
|
||||
- `/webapp-logo`, `/webapp-uploaded-logo/*`, `/webapp-favicon/*`, `/webapp-theme-css/*` и `/webapp-theme-assets/*` тоже проксируются через frontend;
|
||||
- внешний reverse proxy не должен отдельно уводить `/api` или `/auth` на webhook-сервер `backend:8080`.
|
||||
|
||||
Быстрые проверки снаружи:
|
||||
|
||||
```bash
|
||||
curl -i https://app.domain.com/health
|
||||
curl -i https://app.domain.com/api/bootstrap
|
||||
curl -i https://app.domain.com/auth/telegram/start
|
||||
curl -i https://app.domain.com/webapp-theme-css/dark/style.css
|
||||
```
|
||||
|
||||
Если `/health` отвечает, а `/api/bootstrap` или theme assets падают, смотрите одновременно frontend и backend:
|
||||
|
||||
```bash
|
||||
docker compose logs -f frontend backend
|
||||
```
|
||||
|
||||
Где проверять конфигурацию:
|
||||
|
||||
- frontend nginx: `deploy/docker/frontend/nginx.conf`;
|
||||
- внешний Caddy/Nginx: `deploy/examples/caddy/Caddyfile` или `deploy/examples/nginx/nginx.conf.template`;
|
||||
- Web App домен: `SUBSCRIPTION_MINI_APP_URL`, он должен быть публичным HTTPS URL frontend, без `/api`, `/auth` или webhook-пути;
|
||||
- WebApp server backend: `WEBAPP_ENABLED=True`, `WEBAPP_SERVER_HOST=0.0.0.0`, `WEBAPP_SERVER_PORT=8081`.
|
||||
|
||||
## Mini App auth и Telegram OAuth
|
||||
|
||||
Ошибки авторизации почти всегда видны в `backend`, потому что проверка Telegram Mini Apps `initData`, Telegram OAuth `id_token`, nonce/state и сессий выполняется на backend WebApp server.
|
||||
|
||||
```bash
|
||||
docker compose logs -f backend
|
||||
```
|
||||
|
||||
Ищите сообщения:
|
||||
|
||||
- `Telegram WebApp initData hash mismatch`;
|
||||
- `Telegram WebApp initData auth_date is stale`;
|
||||
- `Failed to validate Telegram WebApp initData`;
|
||||
- `Telegram OAuth nonce mismatch`;
|
||||
- `Telegram OAuth ID token is stale`;
|
||||
- `Failed to validate Telegram OAuth ID token`;
|
||||
- `Telegram OAuth token exchange failed`;
|
||||
- `Telegram OAuth callback failed`;
|
||||
- `WebApp auth failed`.
|
||||
|
||||
Для Mini App внутри Telegram проверьте:
|
||||
|
||||
- `SUBSCRIPTION_MINI_APP_URL` совпадает с доменом, указанным в BotFather Mini Apps;
|
||||
- открывается именно HTTPS frontend-домен, а не backend webhook-домен;
|
||||
- время на сервере синхронизировано, иначе `auth_date is stale`;
|
||||
- `WEBAPP_AUTH_MAX_AGE_SECONDS` не слишком маленький;
|
||||
- `WEBAPP_SESSION_SECRET` постоянный между рестартами.
|
||||
|
||||
Для Telegram OAuth вне Mini App проверьте:
|
||||
|
||||
- `TELEGRAM_OAUTH_CLIENT_ID` и `TELEGRAM_OAUTH_CLIENT_SECRET`;
|
||||
- callback в Telegram OAuth/BotFather: `https://app.domain.com/auth/telegram/callback`;
|
||||
- `/auth/telegram/start` и `/auth/telegram/callback` проходят через frontend nginx в `backend:8081`;
|
||||
- в браузере после callback нет статуса `telegram_auth=invalid_state`, `invalid_token`, `not_configured`, `unauthorized` или `failed`.
|
||||
|
||||
Подробности по маршрутам и настройке OAuth: [Web App / Mini App](../features/web-app.md).
|
||||
|
||||
## После изменения конфигурации
|
||||
|
||||
```bash
|
||||
docker compose up -d
|
||||
docker compose logs -f backend worker frontend
|
||||
```
|
||||
|
||||
См. также [проблемы](issues.md) и [развертывание](../deployment.md).
|
||||
Reference in New Issue
Block a user