Зробіть resolve credentials
Пройдіть ланцюг USER → ORGANIZATION → PLATFORM з місця runtime-а й подивіться, як кожен рівень перемагає по черзі.
Погляд із сервісної площини: runtime перекладу просить ефективний ключ, і ланцюг відповідає. Цей сценарій виводить на сцену всі три рівні та промах, тож кожна гілка проходу показує себе.
Мета
Спостерігати, як credential_source змінюється з user на organization і на platform в міру зникнення верхніх рівнів, і закінчити промахом 404 CREDENTIAL_NOT_CONFIGURED.
Передумови
- Сервісний токен зі scope
provider-credentials.invoke:export SERVICE_TOKEN=...(Service Plane Tokens). - Підготовлені записи для одного провайдера: персональний default користувача, default організації, platform-default (сценарії 02, 05, 07).
Кроки
1. Перемагає власний ключ користувача
Викличте POST /internal/v1/credentials/resolve:
curl -s -X POST "$CREDS_BASE/internal/v1/credentials/resolve" \
-H "Authorization: Bearer $SERVICE_TOKEN" -H "Content-Type: application/json" \
-d '{
"user_id": "'$USER_ID'",
"org_id": "'$ORG_ID'",
"provider_code": "'$CODE'",
"purpose": "translation",
"correlation_id": "cookbook-06-a"
}'
Очікуване 200: credential_source: "user" і — унікально для цієї площини — plaintext credentials. Поводьтеся відповідно (Resolve Chain).
2. Приберіть рівень user — вступає організація
Видаліть (або вимкніть) credential користувача, зробіть resolve знову з тим самим тілом. Очікуване 200 з credential_source: "organization", owner_id = UUID організації.
3. Приберіть org із запиту — ловить платформа
Зробіть resolve без org_id. Очікуване 200 з credential_source: "platform" — без контексту організації цей рівень пропускається повністю, і обслуговує спільний fallback.
4. Забороніть fallback — контрольований промах
Той самий запит плюс "allow_platform_fallback": false:
r = httpx.post(f"{CREDS_BASE}/internal/v1/credentials/resolve",
headers={"Authorization": f"Bearer {SERVICE_TOKEN}"},
json={**body, "allow_platform_fallback": False})
assert r.status_code == 404
assert r.json()["error"]["code"] == "CREDENTIAL_NOT_CONFIGURED"
Очікуване 404 CREDENTIAL_NOT_CONFIGURED — провайдер існує, нічого допустимого не налаштовано. Кожен крок цього сценарію, і влучання, і промах, тепер видно в audit-стрічці під вашими correlation id (сценарій 09).
Токени з хибним scope відхиляються, а не деградуються
Повторіть крок 1 з admin-scoped токеном: очікуване 403 FORBIDDEN. Resolve належить лише provider-credentials.invoke.
Перевірено тестом test_s06_resolve_credentials.