Przegląd
user_path to znormalizowana hierarchia wywołującego, na przykład
/team/alpha lub /team/alpha/service.
GoModel używa jej, aby dostęp do modeli, workflow, budżety, użycie i dane audytowe
były przypisane do właściwego zespołu, tenanta, usługi lub klienta.
Klucze API
Ścieżkę użytkownika możesz przypisać do zarządzanego klucza API w dashboardzie administracyjnym:API Keys -> Create API Key -> User Path
user_path obok jego
etykiet, dzięki czemu od razu widzisz, do którego poddrzewa należy dany klucz.
Gdy request używa tego klucza, GoModel traktuje user_path klucza jako
efektywną ścieżkę użytkownika dla requestu.
Nagłówek HTTP
Klienci mogą też wysłać ścieżkę użytkownika bezpośrednio:USER_PATH_HEADER lub
server.user_path_header w config.yaml. Jeśli nie jest ustawiona, GoModel używa
X-GoModel-User-Path.
Jeśli klucz API ma własny user_path, wygrywa klucz. GoModel nadpisuje
wartość nagłówka ścieżką przypisaną do klucza, zanim zostaną uruchomione dopasowanie workflow, logowanie audytowe,
śledzenie użycia i kontrole dostępu do modeli.
Zakres dostępu
Przypisany do kluczauser_path jest też zakresem dostępu klucza: poddrzewem, które
klucz może odczytywać i którym może zarządzać. Klucz przypisany do /team/alpha ma dostęp do /team/alpha i
każdego potomka, ale nie do /team/beta, nie do /team i nie do wierszy zapisanych
bez ścieżki użytkownika. Nagłówek nigdy nie poszerza zakresu; wybiera jedynie
ścieżkę, do której przypisywany jest request.
Reguła jest taka sama dla wszystkich danych uwierzytelniających: ścieżka użytkownika to węzeł, w imieniu którego działasz,
i widzisz ten węzeł oraz wszystko poniżej. Sesja SSO przypisana do
/users/alice administruje więc tylko tym poddrzewem. Rozszerzenie, które chce
nadawać uprawnienia administratorów gatewaya, przypisuje takie sesje do /, a administratorów zespołów do
katalogu głównego zespołu, np. /team/alpha – dokładnie tak, jak utworzyłbyś klucz API pod
tą ścieżką.
Zakres obowiązuje w dwóch miejscach:
- Admin API i dashboard. Klucz z dostępem do dashboardu i
user_pathjest administratorem zakresowym tego poddrzewa. Zobacz Zakresowy dostęp administracyjny. - Własność obiektów na endpointach cyklu życia
/v1, opisana poniżej.
Własność obiektów
Odpowiedzi (responses), konwersacje, batche i przesłane pliki pamiętająuser_path,
pod którym zostały utworzone. Pobranie, wylistowanie, aktualizacja, anulowanie lub usunięcie
takiego obiektu po ID udaje się tylko wtedy, gdy ta ścieżka leży w zakresie wywołującego;
w przeciwnym razie gateway odpowiada 404, dokładnie tak jak dla nieznanego ID.
Wywołanie /v1/responses, które odwołuje się do konwersacji lub
previous_response_id z innego poddrzewa, kończy się tak samo – także u
providerów, które same rozwiązują previous_response_id.
Zakresowe dane uwierzytelniające mogą odwoływać się tylko do obiektów śledzonych przez gateway: ID, którego
gateway nie ma w rejestrze, jest raportowane jako nieistniejące, a GET /v1/files listuje
śledzone pliki wywołującego z własnych rekordów gatewaya, a nie od
providera. Globalne dane uwierzytelniające widzą każdy obiekt, w tym starsze wiersze zapisane,
zanim ścieżka była przechowywana, i nadal odpytują providera o nieśledzone
ID. Używaj trwałego magazynu danych, aby każdy obiekt pozostawał śledzony po restartach.
Dostęp do modeli
Polityki dostępu do modeli są domyślnie włączone. Polityka to model wirtualny bez celu; może używaćuser_paths, aby ograniczyć selektor do poddrzewa, albo być
wyłączona, aby całkowicie wyłączyć selektor. Selektory mogą wskazywać:
/dla wszystkich providerów i modeli{provider_name}/dla jednego skonfigurowanego providera{provider_name}/{model}dla jednego modelu u jednego providera- ID modelu bez nazwy providera
- selektor:
openai/gpt-5 user_paths:["/team/alpha"]
/team/alpha i jego potomków, takich jak /team/alpha/service.
Do zarządzania tymi regułami użyj w dashboardzie Models -> New virtual model: zostaw
Target model puste, aby utworzyć politykę dostępu dla selektora Source.
Przekierowania (aliasy) opisuje strona Modele wirtualne.
Strona Users odpowiada na to samo pytanie z drugiej strony: które modele
może wywołać grupa, użytkownik lub klucz API. Każdy węzeł ścieżki użytkownika i każdy zarządzany klucz API ma
opcjonalną listę allowed_models; listy są przecinane w dół drzewa, więc potomek może
jedynie zawęzić to, na co pozwala jego grupa. Zobacz Użytkownicy.
Udostępniane modele
GET /v1/models również używa efektywnego user_path.
Oznacza to, że dwa klucze API mogą widzieć różne listy modeli, jeśli ich ścieżki użytkownika mają
różne reguły dostępu do modeli.
Workflow
Workflow mogą też zawieraćscope_user_path, dzięki czemu różne zespoły lub usługi mogą
korzystać z różnych ustawień budżetu, cache’u, audytu, użycia, guardrails i failoveru.
Ścieżkę użytkownika możesz łączyć z zakresem providera i modelu, na przykład:
/team/alphaopenai_primary+/team/alphaopenai_primary+gpt-5+/team/alpha
Budżety
Budżety również mają zakres wyznaczany przezuser_path. Budżet dla /team/alpha dotyczy
/team/alpha i potomków, takich jak /team/alpha/service, ale nie ścieżek
sąsiednich, takich jak /team-alpha.
Limity wydatków i egzekwowanie w workflow opisuje strona Budżety.