f52275690f
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2.1 KiB
2.1 KiB
T-2026-001 — Приём заявок с vote: проверка ключа через Auth_server
Часть кросс-проектной задачи T-2026-001. Overview:
C:\project\orchestrator\tasks\T-2026-001-vote-doc-orders\_overview.mdПроект: Doc_manager (doc.queo.ru)
Зависимости
- Делать после: Auth_server (нужен verify-endpoint)
- Блокирует: сквозной тест
- Можно параллельно с: заданием Question
Контекст
Endpoint /api/incoming/orders и раздел /orders уже реализованы. Меняем источник
истины по сайтам/ключам: вместо локальной таблицы Sites — проверка ключа
централизованно через Auth_server.
Что сделать
/api/incoming/orders: входящийX-Site-Keyпроверять через Authverify(а не по локальной таблице Sites); из ответа брать идентичность сайта (siteId/domain).- Кэшировать результат verify (короткий TTL), обрабатывать недоступность Auth (понятная ошибка/повтор, без потери заявки).
- Привязывать созданный Order к siteId из Auth.
- Локальный реестр Sites: вывести из обязательного пути приёма заявок (оставить как кэш/справочник или убрать — по ситуации, не ломая текущие данные).
- Проверить payload (customerName, customerInn, customerEmail, acceptedOfferAt, items[]) и «Перевести в проект» (клиент по ИНН).
Критерий готовности
curlс ключом, выпущенным Auth, проходит verify и создаёт Order(new), видимый в/orders; без валидного ключа — отказ.