mbs-panel/site/privacy.html

72 lines
4.3 KiB
HTML
Raw Normal View History

<!doctype html>
<html lang="ru">
<head>
<meta charset="utf-8">
<meta name="viewport" content="width=device-width, initial-scale=1">
<title>MBS Panel — Политика конфиденциальности</title>
<style>
:root {
--bg: #0a0b0f; --card: #131519; --border: #1e2128;
--text: #eceef2; --muted: #868c99; --accent: #7c6cf0;
--ease: cubic-bezier(0.16, 1, 0.3, 1);
}
* { box-sizing: border-box; }
body {
margin: 0; background: var(--bg); color: var(--text);
font-family: -apple-system, BlinkMacSystemFont, "Segoe UI", Roboto, sans-serif;
-webkit-font-smoothing: antialiased; line-height: 1.6;
}
a { color: var(--accent); }
.wrap { max-width: 720px; margin: 0 auto; padding: 48px 24px 80px; }
.back { color: var(--muted); text-decoration: none; font-size: 14px; }
.back:hover { color: var(--text); }
h1 { font-size: 26px; margin: 24px 0 6px; letter-spacing: -0.02em; }
.updated { color: var(--muted); font-size: 13px; margin-bottom: 36px; }
h2 { font-size: 17px; margin: 36px 0 10px; font-weight: 600; }
p, li { color: var(--text); font-size: 14.5px; }
.muted { color: var(--muted); }
.fill { color: var(--accent); background: rgba(124,108,240,0.1); padding: 1px 5px; border-radius: 4px; }
ol, ul { padding-left: 20px; }
li { margin-bottom: 8px; }
</style>
</head>
<body>
<div class="wrap">
<a class="back" href="/">← На главную</a>
<h1>Политика конфиденциальности</h1>
feat: payments setup wizard — legal pages + YooKassa keys from the admin UI The site/offer.html and site/privacy.html legal templates existed in the repo but were never actually wired to anything — no route served them, install.sh never copied them anywhere. Nobody deploying this for real payments had a live offer/privacy page, which YooKassa requires for merchant approval. Rewrote both templates with {{TOKEN}} placeholders (new legal.py renders them from .env-backed settings, read fresh on every request, no restart needed to fix a typo) and added a proper setup section in the Payments tab: business type/name/INN/support contact/refund window, saved via POST /admin/api/payments/legal-settings, live at GET /offer and /privacy immediately. Unset fields render as a visible not-set-yet badge instead of breaking the page. Effective date auto-stamps once on first save and stays stable across later edits (verified: editing the name afterward doesn't reset it). YooKassa shop_id + secret_key get their own section: validated live against YooKassa's own /v3/me before being saved (same pattern as the existing bot-token getMe check), never echoed back to the frontend once set. Includes an inline guide — where to find the keys in YooKassa's dashboard, and that self-employed registration there needs just passport + INN, no separate cash register. Both new dropdowns use the existing custom .dd component, not a raw select element — this codebase deliberately doesn't use native selects (see the comment already in admin.html) because of the OS-rendered white popup, so a new form had to follow that pattern, not reintroduce it. Verified: template rendering with empty settings (fallback badges, no leftover tokens) and fully filled settings, HTML-escaping of field values (a script tag in a field renders as text, not markup), the one-time-only date stamp, and all new routes registering correctly. Also fixed a stale doc string in the panel's own admin-facing docs tab that still quoted the old rate-limit numbers from before the real limits shipped. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-09-13 19:23:25 +05:00
<p class="updated">Действует с {{EFFECTIVE_DATE}}</p>
feat: payments setup wizard — legal pages + YooKassa keys from the admin UI The site/offer.html and site/privacy.html legal templates existed in the repo but were never actually wired to anything — no route served them, install.sh never copied them anywhere. Nobody deploying this for real payments had a live offer/privacy page, which YooKassa requires for merchant approval. Rewrote both templates with {{TOKEN}} placeholders (new legal.py renders them from .env-backed settings, read fresh on every request, no restart needed to fix a typo) and added a proper setup section in the Payments tab: business type/name/INN/support contact/refund window, saved via POST /admin/api/payments/legal-settings, live at GET /offer and /privacy immediately. Unset fields render as a visible not-set-yet badge instead of breaking the page. Effective date auto-stamps once on first save and stays stable across later edits (verified: editing the name afterward doesn't reset it). YooKassa shop_id + secret_key get their own section: validated live against YooKassa's own /v3/me before being saved (same pattern as the existing bot-token getMe check), never echoed back to the frontend once set. Includes an inline guide — where to find the keys in YooKassa's dashboard, and that self-employed registration there needs just passport + INN, no separate cash register. Both new dropdowns use the existing custom .dd component, not a raw select element — this codebase deliberately doesn't use native selects (see the comment already in admin.html) because of the OS-rendered white popup, so a new form had to follow that pattern, not reintroduce it. Verified: template rendering with empty settings (fallback badges, no leftover tokens) and fully filled settings, HTML-escaping of field values (a script tag in a field renders as text, not markup), the one-time-only date stamp, and all new routes registering correctly. Also fixed a stale doc string in the panel's own admin-facing docs tab that still quoted the old rate-limit numbers from before the real limits shipped. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-09-13 19:23:25 +05:00
<p>Настоящая политика описывает, какие данные собирает и как обрабатывает {{LEGAL_NAME}} (далее — «Оператор») при использовании Telegram-бота и сайта MBS Panel.</p>
<h2>1. Какие данные собираются</h2>
<ul>
<li>Telegram ID и username — для выдачи и учёта подписки, идентификации в боте.</li>
<li>Технический идентификатор VPN-клиента (UUID) — для настройки доступа на сервере, без привязки к личности.</li>
<li>Данные об оплате (сумма, статус, дата, идентификатор транзакции платёжного провайдера) — реквизиты карты Оператору не передаются и не хранятся, это зона ответственности ЮKassa/Platega.</li>
<li>IP-адрес — временно, только для защиты от злоупотреблений (рейт-лимиты), не сохраняется в привязке к трафику пользователя.</li>
</ul>
<p class="muted">Оператор не собирает и не хранит журнал посещаемых через VPN сайтов и не ведёт логи трафика клиентов.</p>
<h2>2. Цели обработки</h2>
<ul>
<li>Предоставление и продление доступа к VPN-сервису.</li>
<li>Обработка оплаты и подтверждение транзакций.</li>
<li>Связь с пользователем по вопросам работы сервиса.</li>
</ul>
<h2>3. Хранение и передача третьим лицам</h2>
<p>Данные хранятся на серверах Оператора и не передаются третьим лицам, кроме платёжных провайдеров (ЮKassa, Platega) в объёме, необходимом для обработки оплаты, и в случаях, прямо предусмотренных законодательством РФ.</p>
<h2>4. Права пользователя</h2>
feat: payments setup wizard — legal pages + YooKassa keys from the admin UI The site/offer.html and site/privacy.html legal templates existed in the repo but were never actually wired to anything — no route served them, install.sh never copied them anywhere. Nobody deploying this for real payments had a live offer/privacy page, which YooKassa requires for merchant approval. Rewrote both templates with {{TOKEN}} placeholders (new legal.py renders them from .env-backed settings, read fresh on every request, no restart needed to fix a typo) and added a proper setup section in the Payments tab: business type/name/INN/support contact/refund window, saved via POST /admin/api/payments/legal-settings, live at GET /offer and /privacy immediately. Unset fields render as a visible not-set-yet badge instead of breaking the page. Effective date auto-stamps once on first save and stays stable across later edits (verified: editing the name afterward doesn't reset it). YooKassa shop_id + secret_key get their own section: validated live against YooKassa's own /v3/me before being saved (same pattern as the existing bot-token getMe check), never echoed back to the frontend once set. Includes an inline guide — where to find the keys in YooKassa's dashboard, and that self-employed registration there needs just passport + INN, no separate cash register. Both new dropdowns use the existing custom .dd component, not a raw select element — this codebase deliberately doesn't use native selects (see the comment already in admin.html) because of the OS-rendered white popup, so a new form had to follow that pattern, not reintroduce it. Verified: template rendering with empty settings (fallback badges, no leftover tokens) and fully filled settings, HTML-escaping of field values (a script tag in a field renders as text, not markup), the one-time-only date stamp, and all new routes registering correctly. Also fixed a stale doc string in the panel's own admin-facing docs tab that still quoted the old rate-limit numbers from before the real limits shipped. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-09-13 19:23:25 +05:00
<p>Пользователь вправе запросить удаление своих данных и прекращение обработки, обратившись на {{SUPPORT_EMAIL}} или {{SUPPORT_CONTACT}}. Удаление данных влечёт прекращение доступа к активным подпискам.</p>
<h2>5. Контакты</h2>
<p class="muted">
feat: payments setup wizard — legal pages + YooKassa keys from the admin UI The site/offer.html and site/privacy.html legal templates existed in the repo but were never actually wired to anything — no route served them, install.sh never copied them anywhere. Nobody deploying this for real payments had a live offer/privacy page, which YooKassa requires for merchant approval. Rewrote both templates with {{TOKEN}} placeholders (new legal.py renders them from .env-backed settings, read fresh on every request, no restart needed to fix a typo) and added a proper setup section in the Payments tab: business type/name/INN/support contact/refund window, saved via POST /admin/api/payments/legal-settings, live at GET /offer and /privacy immediately. Unset fields render as a visible not-set-yet badge instead of breaking the page. Effective date auto-stamps once on first save and stays stable across later edits (verified: editing the name afterward doesn't reset it). YooKassa shop_id + secret_key get their own section: validated live against YooKassa's own /v3/me before being saved (same pattern as the existing bot-token getMe check), never echoed back to the frontend once set. Includes an inline guide — where to find the keys in YooKassa's dashboard, and that self-employed registration there needs just passport + INN, no separate cash register. Both new dropdowns use the existing custom .dd component, not a raw select element — this codebase deliberately doesn't use native selects (see the comment already in admin.html) because of the OS-rendered white popup, so a new form had to follow that pattern, not reintroduce it. Verified: template rendering with empty settings (fallback badges, no leftover tokens) and fully filled settings, HTML-escaping of field values (a script tag in a field renders as text, not markup), the one-time-only date stamp, and all new routes registering correctly. Also fixed a stale doc string in the panel's own admin-facing docs tab that still quoted the old rate-limit numbers from before the real limits shipped. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-09-13 19:23:25 +05:00
{{LEGAL_NAME}}<br>
Email: {{SUPPORT_EMAIL}}<br>
Telegram: {{SUPPORT_CONTACT}}
</p>
</div>
</body>
</html>