Видати API-ключ і вибрати ліміти

Хто в BDO UA Translate видає ключі до Agent API, як обираються здатності й ліміти, чому ключ не може більше за роль власника і що робити при підозрі на витік.

Ключі видає лише супер-адміністратор · це та сама межа, що й на ролях (чому саме так). Робиться це на сторінці конкретної людини, а не окремим розділом: ключ завжди належить людині.

Відкрити користувачів

Головне правило: ключ не додає прав

Ефективне право ключа · це перетин: здатність ключа ∩ право ролі власника. Тому ключем неможливо видати те, чого людина не має в панелі.

Наслідок, який економить час: якщо скрипт отримує 403, питання не в ключі, а в ролі людини. І навпаки · зміна ролі застосовується до ключа одразу, окремо перевидавати його не треба.

Система не дає видати безглузду комбінацію: якщо роль власника не покриває обрану здатність, видача зупиняється з поясненням, а не створює ключ, який мовчки отримуватиме 403.

Здатності · вмикати лише потрібне

Перемикачі відповідають конкретним діям: читати рядки, читати глосарій, перевіряти розмітку, пропонувати переклад чи термін, рецензувати, писати переклади.

Правило просте: увімкніть тільки те, що потрібно цьому скрипту. Вимкнений перемикач забороняє дію, навіть якщо роль її дозволяє · це і є сенс окремих здатностей.

Дві здатності стоять окремо й доступні лише від ролі адміністратора:

  • «Записувати ШІ-переклади» · це операція класу «заливка», а не пропозиція;
  • рецензування глосарія.

Усі інші записи від звичайного ключа йдуть як звичайні пропозиції й проходять модерацію на загальних підставах.

Ліміти

Порожні поля означають ліміти за роллю · окремо нічого вигадувати не треба:

Роль власника Запитів/хв Рядків/добу
Супер-адміністратор і адміністратор 120 5000
Модератор 60 2000
Перекладач 60 1000
Звичайний учасник 30 200

Індивідуальне значення на ключі перекриває дефолт ролі. Ставити його варто тоді, коли є причина: разовий великий прогін або, навпаки, свідоме звуження для чужого скрипта.

Ліміти має навіть супер-адміністратор · це рішення власника, а не недогляд. Скинути лічильники може тільки він.

Важлива деталь: лічильники живуть на людині, а не на ключі. Тому перевидання ключа денну квоту не скидає.

Порядок видачі

  1. Відкрийте сторінку людини.
  2. Дайте ключу назву · вона ні на що не впливає, але через місяць саме за нею зрозуміло, який скрипт ним користується.
  3. Увімкніть потрібні здатності.
  4. Ліміти лишіть порожніми, якщо немає причини.
  5. Видайте ключ і одразу передайте значення власнику.

Один активний ключ на людину. Це навмисно: два діючих ключі неможливо осмислено показати в кабінеті й неможливо потім відкликати «той самий».

Ключ показується один раз

Повне значення існує поза шифрованим сховищем лише в момент видачі й не потрапляє в журнал подій. Кожен показ ключа фіксується в аудиті.

Тому ключ не пересилають у публічних каналах і не вставляють у код · він належить одній людині й одному скрипту.

Якщо ключ скомпрометовано

Перегенерувати. Старе значення перестає працювати тієї ж миті. Квота при цьому не скидається, бо вона рахується на людині.

Якщо проблема не в ключі, а в людині · тоді це блокування акаунта, і воно вимагає причини (як це робиться).

Чого не робити

  • Не видавати ключ із усіма здатностями «про запас» · вимкнений перемикач коштує нічого, а зайвий доступ коштує розбору.
  • Не піднімати роль людині заради ключа. Роль дає доступ і в панелі; якщо потрібна одна можливість · є точкові винятки дозволів.
  • Не ставити високі індивідуальні ліміти без причини: дефолт ролі вже розрахований, а розбирати наслідки доведеться вам (де видно навантаження).