Hitelesítés

A Model Gate gyártási kulcsai ezzel kezdődnek mg_live_. Ugyanaz a kulcs működik az OpenAI-kompatibilis és az Anthropic-kompatibilis kéréseknél is.

OpenAI-kompatibilis fejléc

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

Használja ezt az űrlapot /v1/chat/completions, /v1/responses, /v1/embeddings, /v1/images/generations, /v1/models, és /v1/balance.

Antropikus kompatibilis fejléc

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

Használja ezt az űrlapot /v1/messages és /v1/messages/count_tokens. A hordozó hitelesítést is elfogadják.

Példa kérése

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

Válasz példa

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

Hitelesítetlen végpontok

Csak a szolgáltatás-egészségügyi végpontok nem hitelesítettek:

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

Interaktív böngésző munkamenetek

A Model Gate fiókpanel olyan szerveroldali böngésző-munkamenetet használ, amely elkülönül a Model API kulcsaitól. Alapértelmezés szerint a hitelesített böngészőmunkamenet lejár utána 12 óra hiteles tevékenység nélkül vagy utána 7 nap összesen, amelyik előbb bekövetkezik. A böngésző cookie maga továbbra is munkamenet cookie marad, így a böngésző bezárásával a böngésző viselkedésétől függően előfordulhat, hogy korábban véget ér.

Ha egy fiókpanel-oldal a hitelesítés lejárta után is nyitva van, az AJAX-műveletek HTTP-t adnak vissza 401 JSON kóddal authentication_required a panelen pedig a A munkamenet lejárt prompt ahelyett, hogy a bejelentkezési oldalt JSON-ként kezelné. Egy elavult oldal/CSRF token visszaadja a HTTP-t 419 JSON kóddal csrf_expired és oldalfrissítést kér. A sikertelen mutációkat, beleértve a fizetés inicializálását, a rendszer soha nem játssza le automatikusan a bejelentkezés vagy a frissítés után.

Fiók és IP biztonság

A hitelesített profil lehetővé teszi a TOTP kétfaktoros hitelesítést WinAuth vagy más kompatibilis hitelesítő segítségével. A gazdasági szervezetek minden tag számára megkövetelhetik a TOTP-t; ez a követelmény alapértelmezés szerint engedélyezve van az üzleti szervezetek számára. A befejezett második tényező kihívása az aktuális böngészőmunkamenetben rögzítésre kerül. Az olyan kényes fiókműveletek, mint a hitelesítő adatok létrehozása/felfedése/forgatása, a biztonsági szabályzat megváltoztatása és a biztonsági titkok újratermelése, újabb második tényezős igazolást igényelnek, ha a TOTP engedélyezve van; az aktuális termékablak 15 perc.

A TOTP engedélyezése tíz egyszeri helyreállítási kódot hoz létre. Teljes értékük csak generáláskor jelenik meg; A Model Gate csak kivonatokat tárol, és használat után atomosan felhasznál egy kódot. A helyreállítási kódok újragenerálása érvényteleníti a régebbi, nem használt kódokat. A TOTP-regisztráció megköveteli az aktuális jelszót, ha a fiók rendelkezik ilyennel, vagy egy közelmúltbeli elsődleges OAuth/Telegram-hitelesítést a jelszó nélküli fiókokhoz. A jelszó megváltoztatása, a TOTP engedélyezése/letiltása/visszaállítása és a bejelentkezési biztonsági házirend módosításai visszavonják az elavult böngészőmunkameneteket. A rendszergazdák és a cégtulajdonosok/adminisztrátorok visszaállíthatják a felügyelt felhasználók TOTP-jét, ha helyreállításra van szükség; A reset kijelentkezteti a cél böngésző munkameneteit, de nem vonja vissza a Model API hitelesítő adatait.

A profil bemutatja Hitelesítő alkalmazás (TOTP) és IP engedélyezési listák külön biztonsági ellenőrzésként. A hitelesítő kezdeti regisztrációja megnyit egy modált, és befejezi a beállítást/megerősítést az AJAX-szal, miközben megtartja a normál szerveroldali POST visszaesést. A bejelentkezési/API engedélyezési listák külön módban vannak szerkesztve, és az AJAX-szal mentve ugyanazt a legutóbbi 2FA-szabályozást követően.

A profil különálló bejelentkezési és API IP engedélyezési listákat is támogat. A szabályok pontos IPv4/IPv6-címek vagy CIDR-előtagok. Az üres lista azt jelenti, hogy nincs korlátozás. A cégtulajdonosok/adminisztrátorok emellett a szervezetre kiterjedő bejelentkezési és API engedélyezési listákat is meghatározhatnak. Ha mind a személyes, mind a szervezeti API-szabályok léteznek, a kérés forrásának meg kell egyeznie mindkettővel. Az API IP-házirend által elutasított kérés HTTP-t ad vissza 403 kóddal ip_not_allowed ahol a kompatibilitási válaszformátum hibakódot jelenít meg.

Az üzleti hitelesítési adatok esetében a vállalat tulajdonosa marad a számlázás tulajdonosa, miközben minden hitelesítési adat rögzít egy hitelesítő felhasználót (megbízó). A megbízó aktív állapota, a személyes API IP-címek engedélyezési listája és a felhasználói RPM/konkurencia korlátok vonatkoznak erre a kulcsra; a vállalati mérleg/árazás és a szervezet API IP-politikája továbbra is vállalati hatókörű marad. Az alkalmazotti hitelesítő adatokat egy aktív csoporthoz kell hozzárendelni, és futtatható üzleti engedélyre van szükség (admin vagy developer, a szervezet tulajdonosa/adminisztrátori jogosultsága is elfogadott). billing és viewer a csoportengedélyek nem hajtanak végre Model API forgalmat.

A csoport adminisztrátora kezelheti a csoport kulcsait, de nem fedheti fel vagy forgathatja el a másik hitelesítési megbízónak kiadott titkot; maga az igazgató és a szervezet tulajdonosa/adminisztrátora hozzáférhet ehhez a hitelesítési titokhoz. Ha a tulajdonos-fő titkot megosztották az alkalmazottakkal a 9.6.2 előtt, forgassa el, és adja ki a dedikált alkalmazott-fő hitelesítő adatokat, hogy megbízható alkalmazottankénti visszavonási/IP-viselkedést érjen el.

A TOTP védi az interaktív bejelentkezést és az érzékeny emberi fiókműveleteket. A jelszó, az OAuth és a Telegram bejelentkezés ugyanazt a második tényező házirendjét használja. A helyreállítási kódok egyszer használhatók a TOTP helyett a bejelentkezéshez vagy a lépésekhez. Az érzékeny távirat-parancsokhoz egy második tényezőre van szükség a TOTP regisztrálásakor, és a beküldött kódok törlődnek a tartós Telegram frissítési/beszélgetési tárolóból. A modell API kérések igen nem TOTP-kód kérése vagy érvényesítése: a már kiadott kulcsot a kulcs állapota, a hitelesítési adatok fő állapota/engedélyei, a hatályos IP-engedélyek listája és a futásidejű/számlázási korlátok engedélyezik.

• Tárolja a kulcsokat környezeti változókban vagy titkos kezelőben.
• Soha ne adj kulcsot Gitnek.
• Használjon külön kulcsot minden projekthez vagy külső felhasználóhoz.
• Azonnal fagyassza le vagy forgassa el a sérült kulcsot.
• A modell API-kulcs titkai csak létrehozáskor vagy elforgatáskor jelennek meg.
• A Partner API hordozó tokenek is csak generáláskor/rotációkor jelennek meg, és a Model Gate csak hash formában tárolja őket.
• A visszahívási aláírási titkok csak generáláskor/rotációkor jelennek meg, nyugalmi állapotban pedig titkosítva vannak; tárolja a másolatát egy titkos kezelőben.
• Ha engedélyez egy API IP-engedélyezési listát, vegyen fel minden kimenő NAT/kilépési címet, amely hívhatja a Model Gate-et.