Informations de référence sur l’API REST du plan de données du service Azure Web PubSub

Comme illustré par le graphique de workflow ci-dessus, ainsi que le workflow détaillé décrit dans internals, votre serveur d’applications peut envoyer des messages aux clients ou gérer les clients connectés à l’aide d’API REST exposées par le service Web PubSub. Cet article décrit en détail les API REST.

Utilisation de l'API REST

Noms de groupes et identifiants utilisateurs dans les chemins de requête

Les opérations REST qui incluent un nom de groupe ou un identifiant utilisateur dans le chemin de requête ont une limitation avec des barres oblique (/) dans ces valeurs. L’encodage URL de la barre oblique pourrait %2F ne pas résoudre la limitation : l’opération peut ne pas s’adresser au groupe ou à l’utilisateur visé. Par exemple, un client connecté à l’identifiant tenant/alice utilisateur peut ne pas être trouvé par une requête REST dont le chemin contient /users/tenant%2Falice.

Cette limitation s’applique aux opérations utilisant ces paramètres de chemin, telles que l’envoi de messages, la vérification de l’existence d’un groupe ou d’un utilisateur, la fermeture de connexions et la gestion de l’appartenance au groupe. Les méthodes du SDK serveur qui appellent ces terminaux REST sont soumises à la même limitation. Il s’agit d’une limitation du chemin de la requête REST, pas d’une interdiction générale des / noms de groupes ou identifiants utilisateurs dans le Web PubSub.

Pour éviter cette limitation, utilisez les noms de groupes et les identifiants d’utilisateur sans / que votre application ait besoin de ces opérations REST. Si les identifiants de votre application contiennent /, associez-les à des identifiants uniques sans barre oblique et utilisez les valeurs mappées de manière cohérente dans les jetons d’accès client, l’appartenance au groupe et les appels REST. Changer uniquement la valeur dans la requête REST ne modifie pas l’identifiant utilisateur ni le nom de groupe associé à une connexion existante.

S’authentifier via une clé d’accès Azure Web PubSub Service

Dans chaque requête HTTP, un en-tête d’autorisation avec un jeton web JSON (JWT) est requis pour s’authentifier auprès d’Azure Web PubSub Service.

Algorithme de signature et signature

HS256, à savoir HMAC-SHA256, est utilisé comme algorithme de signature.

Vous devriez utiliser la chaîne de connexion de l'AccessKeyinstance du service Azure Web PubSub pour signer le JWT généré.

Revendications

Les revendications ci-dessous doivent être incluses dans le JWT.

Un pseudo-code dans JS :

Des chaînes de connexion brutes sont utilisées dans cet article uniquement à des fins de démonstration. Dans les environnements de production, protégez toujours vos clés d’accès. Utilisez Azure Key Vault pour gérer et faire pivoter vos clés en toute sécurité et sécuriser votre connexion avec WebPubSubServiceClient.

const bearerToken = jwt.sign({}, connectionString.accessKey, {
  audience: request.url,
  expiresIn: "1h",
  algorithm: "HS256",
});

S’authentifier via le jeton Microsoft Entra

Comme l’utilisation de AccessKey, un jeton web JSON (JWT) est également nécessaire pour authentifier la requête HTTP.

La différence, c’est que dans ce scénario, JWT est généré par Microsoft Entra ID.

Découvrez comment générer des jetons Microsoft Entra

L’étendue des informations d’identification utilisée doit être https://webpubsub.azure.com/.default.

Vous pouvez également utiliser le contrôle d’accès en fonction du rôle (RBAC) pour autoriser la requête de votre serveur à Azure Web PubSub Service.

Apprenez à ajouter des attributions de rôles

API