Удостоверяване

Производствените ключове на модела Gate започват с mg_live_. Същият ключ работи за OpenAI-съвместими и Anthropic-съвместими заявки.

OpenAI-съвместим хедър

Authorization: Bearer mg_live_...
Content-Type: application/json

Използвайте този формуляр за /v1/chat/completions, /v1/responses, /v1/embeddings, /v1/images/generations, /v1/models, и /v1/balance.

Антропно-съвместим хедър

x-api-key: mg_live_...
anthropic-version: 2023-06-01
content-type: application/json

Използвайте този формуляр за /v1/messages и /v1/messages/count_tokens. Удостоверяването на носителя също се приема.

Пример за заявка

curl https://api.model-gate.com/v1/models \
  -H "Authorization: Bearer mg_live_..."

Пример за отговор

{
  "object": "list",
  "data": []
}

Неавтентифицирани крайни точки

Само крайните точки за изправност на услугата не са удостоверени:

GET /health
GET /health/live
GET /health/ready

Интерактивни сесии на браузъра

Панелът на акаунта на Model Gate използва сесия на браузър от страна на сървъра, която е отделна от ключовете на API на Model. По подразбиране удостоверената сесия на браузъра изтича след 12 часа без удостоверена дейност или след това Общо 7 дни, което от двете настъпи първо. Самата бисквитка на браузъра остава бисквитка на сесия, така че затварянето на браузъра може да го прекрати по-рано в зависимост от поведението на браузъра.

Когато страницата на панела на акаунта е все още отворена след изтичане на удостоверяването, действията на AJAX връщат HTTP 401 JSON с код authentication_required и панелът показва a Сесията е изтекла вместо да третира страницата за вход като JSON. Остаряла страница/CSRF токен връща HTTP 419 JSON с код csrf_expired и иска опресняване на страницата. Неуспешните мутации, включително инициализацията на плащането, никога не се възпроизвеждат автоматично след влизане или опресняване.

Сигурност на акаунт и IP

Удостовереният профил може да активира TOTP двуфакторно удостоверяване с WinAuth или друг съвместим удостоверител. Бизнес организациите могат да изискват TOTP за всеки член; това изискване е активирано по подразбиране за бизнес организации. Завършеното второфакторно предизвикателство се записва в текущата сесия на браузъра. Чувствителни действия в акаунта като създаване/разкриване/завъртане на идентификационни данни, промяна на политиката за сигурност и повторно генериране на тайни за сигурност изискват скорошно доказателство от втори фактор, когато TOTP е активиран; текущият продуктов прозорец е 15 минути.

Активирането на TOTP създава десет еднократни кода за възстановяване. Техните пълни стойности се показват само когато са генерирани; Model Gate съхранява само хешове и атомарно консумира код след употреба. Повторното генериране на кодове за възстановяване обезсилва по-старите неизползвани кодове. Записването в TOTP изисква текущата парола, когато акаунтът има такава, или скорошно основно OAuth/Telegram удостоверяване за акаунти без парола. Промените на паролата, активирането/деактивирането/нулирането на TOTP и промените в политиката за сигурност при влизане отменят остарелите сесии на браузъра. Администраторите и собствениците/администраторите на бизнес могат да нулират TOTP на управляван потребител, когато е необходимо възстановяване; това нулиране подписва сесиите на браузъра на целта, но не отменя идентификационните данни на API на модела.

Профилът представя Приложение за удостоверяване (TOTP) и Списъци с разрешени IP адреси като отделни контроли за сигурност. Първоначалното регистриране на автентификатора отваря модален и завършва настройката/потвърждението с AJAX, като запазва нормалния резервен POST от страната на сървъра. Списъците с разрешени вход/API се редактират в отделен модал и се запазват с AJAX след същите скорошни 2FA правила за повишаване.

Профилът също така поддържа отделни списъци с разрешени IP адреси за влизане и API. Правилата са точни IPv4/IPv6 адреси или CIDR префикси. Празен списък означава липса на ограничения. Собствениците на фирми/администраторите могат допълнително да дефинират списъци с разрешени данни за вход и API за цялата организация. Когато съществуват лични и организационни правила за API, източникът на заявка трябва да съответства и на двете. Заявка, отхвърлена от API IP политика, връща HTTP 403 с код ip_not_allowed където форматът на отговор за съвместимост излага код на грешка.

За бизнес идентификационни данни собственикът на компанията остава собственикът на фактурирането, докато всеки идентификационен номер записва потребител на идентификационни данни (принципал). Активният статус на принципала, списъкът с разрешени IP адреси на личния API и ограниченията за RPM/конкурентност на потребителя се прилагат за този ключ; политиката за IP на API на компанията за баланс/ценообразуване и организация остават обхват на компанията. Идентификационните данни на служителите трябва да бъдат присвоени на активна група и да изискват изпълнимо бизнес разрешение (admin или developer, като се приемат и права на собственик/администратор на организацията). billing и viewer груповите разрешения не изпълняват трафик на API на модела.

Администратор на група може да управлява ключове в тази група, но не може да разкрие или завърти тайна, издадена на друг принципал на идентификационни данни; самият принципал и собственикът/администраторът на организацията имат достъп до тази тайна на идентификационните данни. Ако тайна собственик-принципал е била споделена със служители преди 9.6.2, завъртете я и издайте специални идентификационни данни на служител-принципал, за да получите надеждно поведение на отмяна/IP за всеки служител.

TOTP защитава интерактивното влизане и чувствителните действия на човешки акаунт. Паролата, OAuth и влизането в Telegram използват една и съща политика за втори фактор. Кодовете за възстановяване могат да се използват веднъж вместо TOTP за влизане или преминаване. Чувствителните команди на Telegram изискват втори фактор, когато се регистрира TOTP, а изпратените кодове се редактират от трайно хранилище за актуализиране/разговори на Telegram. Заявките за API на модела го правят не подкана за или валидиране на TOTP код: вече издаден ключ е разрешен от състоянието на ключа, статус/разрешения на идентификационни данни-принципал, ефективни списъци с разрешени IP адреси и ограничения за време на изпълнение/фактуриране.

• Съхранявайте ключовете в променливи на средата или таен мениджър.
• Никога не ангажирайте ключ към Git.
• Използвайте отделен ключ за всеки проект или външен потребител.
• Замразете или завъртете незабавно компрометиран ключ.
• Тайните на API-ключа на модела се показват само при създаване или ротация.
• Partner API носещи токени също се показват само при генериране/завъртане и се съхраняват само хеширани от Model Gate.
• Тайните за подписване на обратно извикване се показват само при генериране/завъртане и се криптират в покой; съхранявайте вашето копие в таен мениджър.
• Ако активирате списък с разрешени IP адреси на API, включете всеки изходящ NAT/изходящ адрес, който може да извика Model Gate.