Головна/Рецепти (Cookbook)/Зробіть resolve credentials ENУКРРУС API-довідник (ReDoc) ↗

Зробіть 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.