Ключі і доступи: чим захищений кожен стик

Вхід за email (PORTAL_AUTH_MODE=email): Supabase Auth надсилає код або посилання, браузер отримує лише HttpOnly-куку gc-auth
proxy.ts перевіряє сесію в Supabase Auth (серверний SUPABASE_PUBLISHABLE_KEY) і роль: клієнт або менеджер; адмін - прапорець менеджера
Без сесії відкриті сторінки й маршрути входу та статика. Підтверджена пошта без ролі бачить тільки каталог і фото
Ролі задає лише сервер: PORTAL_AUTH_MEMBERS, PORTAL_ADMIN_EMAILS і таблиця portal_members
Worker сайту передає шляхи порталу без змін, а свій вхід звіряє через міст /api/preview-auth із заголовком x-preview-auth-secret
База порталу: сервер ходить одним підключенням DATABASE_URL; RLS на таблицях закриває прямий Data API Supabase

Маршрути /api/sync стоять поза proxy.ts і самі звіряють Authorization: Bearer: без секрету в оточенні - 503, з хибним - 401
CRON_SECRET: Vercel Cron бере його зі змінної проєкту, Supabase Cron - із Vault
ORDERS_SYNC_SECRET пускає лише знімки замовлень і боргу; той самий маршрут приймає SYNC_INBOUND_SECRET для push із 1С, але модуль push у збірку розширення не входить
ORDERS_DISPATCH_SECRET окремий: збіг з іншим службовим ключем рахується як відсутній ключ
Фото: шлюз - частина Worker сайту. Vercel має лише ключ читання, ключ запису - тільки у виконавця; однакові значення шлюз не приймає, R2 без публічної адреси
Де лежать значення: серверні змінні проєкту на Vercel, Supabase Vault для розкладу, локальні env-файли виконавця з правами 0600, поза git

Кожен OData-запит порталу несе Basic із BAS_ODATA_USER та BAS_ODATA_PASSWORD і, коли задано BAS_EDGE_KEY, заголовок X-Portal-Key; клієнт один для API і синку
Шлюз на стенді - тунель Cloudflare і правило веб-сервера: пускає лише шляхи OData і /hs/portal із правильним ключем; для бойової 1С документи радять правило WAF
Basic перевіряє сама 1С: за документами OData працює під окремим службовим користувачем бази
Окремий виконавець ходить до OData приватною мережею, повз шлюз
Сервіс прт_Портал звіряє Authorization: Bearer з ТокенВхідний із регістру прт_Налаштування; порожній токен - відмова всім

Клієнт сервісу /hs/portal є лише в робочій гілці: у main портал ходить до 1С тільки через OData
Він слатиме Authorization: Bearer із BAS_SERVICE_TOKEN на адресу BAS_SERVICE_URL і той самий X-Portal-Key
За проєктом адаптера ці дві змінні отримує кожен, хто доставляє чергу: сервер порталу і окремий виконавець
Перемикачі ORDERS_CREATE_VIA і ORDERS_CHANGE_VIA (типово odata) розбираються в тій самій гілці; стан черги rejected - поки лише в проєкті
Bearer і Basic ділять заголовок Authorization, тому для бойової бази документи радять дві окремі публікації; на тестовій сервіс працює під обліковим записом із файла публікації
З боку 1С перевірка токена вже є в коді розширення