Autentifikacija

Autentificirajte sve zahtjeve API-ja Model Gate jednim proizvodnim API ključem.

Proizvodni ključevi modela Gate počinju s mg_live_. Isti ključ radi za OpenAI-kompatibilne i Anthropic-kompatibilne zahtjeve.

Zaglavlje kompatibilno s OpenAI-om

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

Koristite ovaj obrazac za /v1/chat/completions, /v1/responses, /v1/embeddings, /v1/images/generations, /v1/models, i /v1/balance.

Antropokompatibilno zaglavlje

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

Koristite ovaj obrazac za /v1/messages i /v1/messages/count_tokens. Također je prihvaćena autentifikacija nositelja.

Primjer zahtjeva

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

Primjer odgovora

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

Neautentificirane krajnje točke

Samo krajnje točke ispravnosti usluge nisu autentificirane:

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

Interaktivne sesije preglednika

Ploča računa Model Gate koristi sesiju preglednika na strani poslužitelja koja je odvojena od ključeva API modela. Prema zadanim postavkama, autentificirana sesija preglednika istječe nakon 12 sati bez provjerene aktivnosti ili poslije 7 dana ukupno, što god prvo nastupi. Sam kolačić preglednika ostaje kolačić sesije, pa ga zatvaranje preglednika može prekinuti ranije, ovisno o ponašanju preglednika.

Kada je stranica ploče računa još uvijek otvorena nakon isteka provjere autentičnosti, AJAX radnje vraćaju HTTP 401 JSON s kodom authentication_required a ploča prikazuje a Sesija je istekla umjesto da stranicu za prijavu tretira kao JSON. Ustajala stranica/CSRF token vraća HTTP 419 JSON s kodom csrf_expired i traži osvježenje stranice. Neuspjele mutacije, uključujući inicijalizaciju plaćanja, nikada se automatski ne reproduciraju nakon prijave ili osvježavanja.

Sigurnost računa i IP-a

Autentificirani profil može omogućiti TOTP dvofaktorsku autentifikaciju s WinAuth ili drugim kompatibilnim autentifikatorom. Poslovne organizacije mogu zahtijevati TOTP za svakog člana; ovaj je zahtjev prema zadanim postavkama omogućen za poslovne organizacije. Dovršeni izazov drugog faktora bilježi se u trenutnoj sesiji preglednika. Osjetljive radnje računa kao što su stvaranje/otkrivanje/rotiranje vjerodajnica, promjena sigurnosne politike i ponovno generiranje sigurnosnih tajni zahtijevaju nedavni dokaz drugog faktora kada je TOTP omogućen; zadani prozor za potvrdu je 60 minuta (konfigurirao TWO_FACTOR_STEP_UP_TTL_SECONDS). Ovo ne mijenja razdoblje koda autentifikatora od 30 sekundi.

Omogućavanje TOTP-a stvara deset jednokratnih kodova za oporavak. Njihove pune vrijednosti prikazuju se samo kada su generirane; Model Gate pohranjuje samo hashove i atomski troši kod nakon upotrebe. Ponovno generiranje kodova za oporavak poništava starije neiskorištene kodove. TOTP prijava zahtijeva trenutnu lozinku ako je račun ima ili nedavnu primarnu OAuth/Telegram provjeru autentičnosti za račune bez lozinke. Promjene lozinke, TOTP omogućavanje/onemogućavanje/poništavanje i promjene sigurnosnih pravila za prijavu opozivaju zastarjele sesije preglednika. Administratori i vlasnici/administratori tvrtke mogu resetirati TOTP upravljanog korisnika kada je potreban oporavak; taj reset potpisuje sesije ciljnog preglednika, ali ne opoziva vjerodajnice Model API-ja.

Profil predstavlja Aplikacija autentifikatora (TOTP) i IP dopuštene liste kao zasebne sigurnosne kontrole. Početni upis autentifikatora otvara modal i dovršava postavljanje/potvrdu s AJAX-om uz zadržavanje uobičajenog zamjenskog POST-a na strani poslužitelja. Popisi dopuštenih za prijavu/API uređuju se u zasebnom modalu i spremaju s AJAX-om nakon iste nedavne politike pojačanja 2FA.

Profil također podržava zasebne popise dopuštenih IP adresa za prijavu i API. Pravila su točne IPv4/IPv6 adrese ili CIDR prefiksi. Prazna lista znači da nema ograničenja. Vlasnici tvrtki/administratori mogu dodatno definirati popise dopuštenih za prijavu i API za cijelu organizaciju. Kada postoje i osobna i organizacijska API pravila, izvor zahtjeva mora odgovarati obama. Zahtjev odbijen API IP politikom vraća HTTP 403 sa šifrom ip_not_allowed gdje format odgovora kompatibilnosti otkriva kod pogreške.

Za poslovne vjerodajnice, vlasnik tvrtke ostaje vlasnik naplate dok svaka vjerodajnica bilježi korisnika vjerodajnice (principal). Aktivni status principala, osobni API IP dopušteni popis i korisnička ograničenja RPM-a/konkurentnosti primjenjuju se na taj ključ; ravnoteža/cijene tvrtke i politika IP-a API-ja za organizaciju ostaju unutar tvrtke. Vjerodajnice zaposlenika moraju biti dodijeljene aktivnoj grupi i zahtijevaju izvršnu poslovnu dozvolu (admin ili developer, uz prihvaćanje ovlasti vlasnika/administratora organizacije). billing i viewer dopuštenja grupe ne izvršavaju promet Model API-ja.

Administrator grupe može upravljati ključevima u toj grupi, ali ne može otkriti ili rotirati tajnu izdanu drugom principalu vjerodajnice; sam principal i vlasnik/admin organizacije mogu pristupiti toj tajnoj vjerodajnici. Ako je tajna vlasnika-principala podijeljena sa zaposlenicima prije 9.6.2, rotirajte je i izdajte namjenske vjerodajnice za zaposlenika-principala da biste dobili pouzdano opoziv/IP ponašanje po zaposleniku.

TOTP štiti interaktivnu prijavu i osjetljive radnje ljudskog računa. Lozinka, OAuth i prijava na Telegram koriste ista pravila drugog faktora. Kodovi za oporavak mogu se koristiti jednom umjesto TOTP-a za prijavu ili pristup. Osjetljive naredbe Telegrama zahtijevaju drugi faktor kada se upisuje TOTP, a dostavljeni kodovi se redigiraju iz izdržljive pohrane ažuriranja/razgovora Telegrama. Zahtjevi API-ja za model rade ne zatražiti ili potvrditi TOTP kod: već izdani ključ autoriziran je stanjem ključa, statusom/dopuštenjima principala vjerodajnica, efektivnim popisima dopuštenih IP adresa i ograničenjima vremena izvođenja/naplate.

  • Spremite ključeve u varijable okruženja ili tajnog upravitelja.
  • Nikada nemojte predavati ključ Gitu.
  • Koristite poseban ključ za svaki projekt ili vanjskog korisnika.
  • Odmah zamrznite ili rotirajte ugroženi ključ.
  • Tajne API ključa modela prikazuju se samo pri stvaranju ili rotaciji.
  • Nosivi tokeni Partner API također se prikazuju samo pri generiranju/rotaciji i Model Gate ih pohranjuje samo kao hash.
  • Tajne potpisivanja povratnog poziva prikazuju se samo pri generiranju/rotaciji i šifriraju se dok miruju; pohranite svoju kopiju u tajni upravitelj.
  • Ako omogućite API IP dopušteni popis, uključite svaku izlaznu NAT/izlaznu adresu koja može pozvati Model Gate.

Dijeljeni projektni ključevi u Playgroundu

Programeri i administratori poslovnih projekata mogu odabrati projektne ključeve u Playgroundu čak i kada je drugi član kreirao ključ. Privremena vjerodajnica preglednika koristi prijavljenog zaposlenika kao svoj identitet izvršenja: primjenjuje se njihova trenutna grupna dozvola, osobna API IP politika i ograničenja po korisniku. Upotreba ključa/grupe i stvarna naplata ostaju povezani s tvrtkom. Ovo ne otkriva tajnu ključa za višekratnu upotrebu drugog člana niti daje razvojnom programeru pristup novčaniku tvrtke. Sesije preglednika ne mogu poslati odgođene asinkrone ili skupne poslove; koristite namjensku dugotrajnu vjerodajnicu za te integracije.

Kontrole korištenja čitanja

Prikaz API ključeva i grupa ključeva Ograničenje upotrebe, USD protiv upotrebe koja se može poništiti, a ne doživotnog troška. Primjenjuju se gornje granice ključa i grupe; nula uklanja samo strop na tom objektu. RPM i istovremenost zasebna su ograničenja broja zahtjeva, a dostupno stanje novčanika još je jedan preduvjet.

Vlasnik grupe može odabrati Ponovno postavljanje upotrebe u Grupama nakon uobičajene sigurnosne potvrde. Ovo briše samo grupni brojač; ponovno postavljanje ključa u proširenom retku API ključeva briše samo taj ključ. Nijedna radnja ne vraća uplatu, ne mijenja doživotnu potrošnju niti briše zahtjeve. Preostala kvota i zadnje vrijeme resetiranja prikazani su pored kontrola.

Cijenjena upotreba nasljeđuje osnovu cijene i množitelj neovisno od ključa do grupe. To nije još jedno terećenje novčanika. Računovodstvo se povremeno obračunava, tako da zahtjevi tijekom leta mogu prijeći kvotu ili završiti nakon resetiranja; ovo su ograničenja pristupa, a ne točna rezervacija buduće potrošnje.