Видати API-ключ і вибрати ліміти
Хто в BDO UA Translate видає ключі до Agent API, як обираються здатності й ліміти, чому ключ не може більше за роль власника і що робити при підозрі на витік.
Ключі видає лише супер-адміністратор · це та сама межа, що й на ролях (чому саме так). Робиться це на сторінці конкретної людини, а не окремим розділом: ключ завжди належить людині.
Головне правило: ключ не додає прав
Ефективне право ключа · це перетин: здатність ключа ∩ право ролі власника. Тому ключем неможливо видати те, чого людина не має в панелі.
Наслідок, який економить час: якщо скрипт отримує 403, питання не в ключі, а в ролі людини. І навпаки · зміна ролі застосовується до ключа одразу, окремо перевидавати його не треба.
Система не дає видати безглузду комбінацію: якщо роль власника не покриває обрану здатність, видача зупиняється з поясненням, а не створює ключ, який мовчки отримуватиме 403.
Здатності · вмикати лише потрібне
Перемикачі відповідають конкретним діям: читати рядки, читати глосарій, перевіряти розмітку, пропонувати переклад чи термін, рецензувати, писати переклади.
Правило просте: увімкніть тільки те, що потрібно цьому скрипту. Вимкнений перемикач забороняє дію, навіть якщо роль її дозволяє · це і є сенс окремих здатностей.
Дві здатності стоять окремо й доступні лише від ролі адміністратора:
- «Записувати ШІ-переклади» · це операція класу «заливка», а не пропозиція;
- рецензування глосарія.
Усі інші записи від звичайного ключа йдуть як звичайні пропозиції й проходять модерацію на загальних підставах.
Ліміти
Порожні поля означають ліміти за роллю · окремо нічого вигадувати не треба:
| Роль власника | Запитів/хв | Рядків/добу |
|---|---|---|
| Супер-адміністратор і адміністратор | 120 | 5000 |
| Модератор | 60 | 2000 |
| Перекладач | 60 | 1000 |
| Звичайний учасник | 30 | 200 |
Індивідуальне значення на ключі перекриває дефолт ролі. Ставити його варто тоді, коли є причина: разовий великий прогін або, навпаки, свідоме звуження для чужого скрипта.
Ліміти має навіть супер-адміністратор · це рішення власника, а не недогляд. Скинути лічильники може тільки він.
Важлива деталь: лічильники живуть на людині, а не на ключі. Тому перевидання ключа денну квоту не скидає.
Порядок видачі
- Відкрийте сторінку людини.
- Дайте ключу назву · вона ні на що не впливає, але через місяць саме за нею зрозуміло, який скрипт ним користується.
- Увімкніть потрібні здатності.
- Ліміти лишіть порожніми, якщо немає причини.
- Видайте ключ і одразу передайте значення власнику.
Один активний ключ на людину. Це навмисно: два діючих ключі неможливо осмислено показати в кабінеті й неможливо потім відкликати «той самий».
Ключ показується один раз
Повне значення існує поза шифрованим сховищем лише в момент видачі й не потрапляє в журнал подій. Кожен показ ключа фіксується в аудиті.
Тому ключ не пересилають у публічних каналах і не вставляють у код · він належить одній людині й одному скрипту.
Якщо ключ скомпрометовано
Перегенерувати. Старе значення перестає працювати тієї ж миті. Квота при цьому не скидається, бо вона рахується на людині.
Якщо проблема не в ключі, а в людині · тоді це блокування акаунта, і воно вимагає причини (як це робиться).
Чого не робити
- Не видавати ключ із усіма здатностями «про запас» · вимкнений перемикач коштує нічого, а зайвий доступ коштує розбору.
- Не піднімати роль людині заради ключа. Роль дає доступ і в панелі; якщо потрібна одна можливість · є точкові винятки дозволів.
- Не ставити високі індивідуальні ліміти без причини: дефолт ролі вже розрахований, а розбирати наслідки доведеться вам (де видно навантаження).