Groupes de ressources
Configurez les groupes de ressources et accordez un accès direct à leurs membres.
Un groupe de ressources sélectionne des comptes d’abonnement et des canaux API d’un même espace de travail. Créez des groupes distincts selon les ressources ou modèles nécessaires aux membres. Les associations entre espaces de travail sont interdites.
Types de ressources et routage
Les groupes de ressources lient les clés de passerelle personnelles, les autorisations des membres et les politiques modèles. API les canaux séparés; chaque type de ressource a sa propre page de gestion tout en conservant l'isolement de l'espace de travail.
Les nouveaux groupes d'assurance-chômage préfèrent les abonnements avec API Un groupe mixte utilise API les canaux pour les nouvelles demandes seulement lorsque le retour en arrière est explicitement activé et qu'aucun abonnement admissible n'est disponible. API-seul le groupe utilise ses canaux sélectionnés directement. API ou de conserver la préférence client-protocole. API les appels peuvent consommer l'équilibre en amont; SubLane ne demande pas cet équilibre.
Les mises à jour préservent la préférence de protocole et les liens clés des groupes existants. Les conversations existantes ne se déplacent jamais vers une autre ressource après les changements de routage. Désactiver le repli ou supprimer/désactiver une ressource liée peut échouer sa conversation existante plutôt que de changer son identité.
La direction API garde /api/groups et compatible account_ids charge utile. La nouvelle UI envoie resources (kind: "subscription" ou "channel" et ressources id) et routing (preference, allow_api_fallback). Les représentations mixtes de membres, les ID dupliqués et les types de ressources incorrectes sont rejetés.
Déroulement de l ' administrateur
- Dans l'espace de travail sélectionné, ouvrir Groupes de ressources et créer un groupe nommé. Sélectionnez des comptes d'abonnement et API Les nouvelles ressources restent non affectées jusqu'à ce qu'elles soient sélectionnées pour un groupe.
- Ouvrir Membres Une autorisation s'applique directement à ce membre; il n'y a pas d'équipes de personnel; les nouveaux membres et les nouveaux groupes ne reçoivent pas de autorisations automatiques.
- Les membres créent une clé personnelle pour un groupe activé auquel ils peuvent accéder. Chaque clé est liée en permanence à cet espace de travail et à ce groupe.
Les groupes non gérés peuvent partager le même compte en amont dans un espace de travail. A Montant de la prime de ressources Une fois qu'un groupe dispose d'une allocation, son appartenance aux ressources reste fixe pendant que l'allocation existe, même si elle est suspendue. Désactivation d'un groupe ou révocation d'une autorisation de membre bloque les demandes futures et WebSocket se tourne sans déplacer une conversation existante vers une autre ressource.
Un espace de travail supporte jusqu'à 32 groupes et 100 associations de ressources par groupe. Les groupes peuvent être renommés et désactivés. L'interface actuelle ne supprime pas les groupes. Les limites des demandes des membres et les quotas de ressources sont configurés séparément.
La capture d'écran suivante provient d'une version antérieure avec les étiquettes de groupe de ressources; l'éditeur de groupe de ressources actuel liste également API canaux et préférences de routage:
Comportement de la demande et de la conversation
- La création de clé vérifie l'accès actuel des membres et des groupes dans la même transaction que l'insertion de clé.
- Chaque demande et WebSocket tour revérifie l'état de l'espace de travail, l'adhésion, le statut de clé, l'accès de groupe et la politique modèle.
- La découverte et l'inférence n'utilisent que les comptes admissibles dans le groupe lié. Une demande ne peut utiliser un compte que si son catalogue sauvegardé supporte le modèle demandé.
- L'affinité de conversation est étendue au membre, au groupe et à la session. Si son compte lié devient indisponible ou quitte le groupe, la conversation échoue plutôt que de changer silencieusement de compte.
- Une demande déjà acceptée peut se terminer après un changement de autorisation; la prochaine demande ou tour voit la nouvelle politique.
HTTP les paramètres
Les paramètres de gestion nécessitent un rôle d'administrateur dans l'espace de travail sélectionné. Les demandes de navigateur portent la sélection de l'espace de travail et nécessitent une protection d'origine identique pour les mutations.
| Itinéraire | Objet |
|---|---|
GET /api/groups / POST /api/groups | Lister ou créer des groupes dans l'espace de travail sélectionné |
GET /api/groups/{id} / PATCH /api/groups/{id} | Lire ou mettre à jour un groupe propriétaire |
GET /api/groups/{id}/members | Liste directement accordée, membres autorisés |
GET /api/groups/members/{userId} | Lister les autorisations d'un membre dans cet espace de travail |
PUT /api/groups/members/{userId} | Remplacer atomiquement les autorisations de ce membre dans cet espace de travail |
GET /api/keys/groups | Liste des groupes actuellement à la disposition du membre |
La passerelle identifie l'espace de travail à partir de la clé authentifiée, et non l'en-tête de sélection du navigateur. Voir Espaces de travail et Clés API.
Modèle d'accès
Un administrateur peut activer Modèles de limites autorisés Entrer jusqu'à 100 ID exacts, un par ligne, en utilisant les ID retournés par /v1/models. Les ID autochtones permettent ce modèle exact à l'ensemble des fournisseurs d'appui du groupe. Les règles existantes qualifiées pour les fournisseurs conservent leur portée initiale; mise à jour SubLane ne les réécrivent pas ou ne les élargissent pas. Les règles qualifiées du legacy peuvent toujours être soumises explicitement. Les Wildcards ne sont pas pris en charge et les variantes de modèles doivent être énumérées explicitement.
Les groupes restent libres par défaut, y compris les nouveaux modèles découverts. L'activation de la licenselist sans entrée nie tous les modèles. API accepte une option model_policy: {"restricted": true, "models": ["synthetic-model"]} o Omission conserve une politique existante; elle ne réinitialise pas l'accès. restricted_models; les réponses détaillées comprennent également: allowed_models.
La découverte de modèles filtre les modèles en dehors de la liste d'autorisation et ne contacte pas les fournisseurs totalement exclus par la politique. Responses, Chat Completions, compactage, et chaque WebSocket tour (y compris préchauffage local) vérifier la politique actuelle avant la sélection du compte ou le travail en amont. 403 model_not_allowed; elle ne consomme pas de taux de participation/d'allocation d’usage de change et ne crée aucune affinité. Les demandes déjà acceptées peuvent être terminées.
Modèles découverts automatiquement
Ouvrir Modèles La liste suit l'adhésion au compte et applique la liste d'autorisation existante; ce n'est pas une deuxième copie modifiable de cette politique. De nouveaux modèles en amont apparaissent automatiquement seulement dans des groupes illimités. Les restrictions explicites, y compris une liste de refus vide, restent inchangées par synchronisation.
Inférence utilise le support de catalogue spécifique à un compte avant d'appliquer les règles normales de charge/refroidissement. Les comptes avec différentes capacités d'abonnement peuvent partager un groupe : une demande est admissible uniquement pour les comptes qui ont déclaré son modèle. catalogues de modèles pour la fraîcheur, les échecs et l'affinité de la conversation.