Désinscription de WebSocket connexions à l'aide de filtres dans AWS AppSync

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Dans AWS AppSync, vous pouvez vous désinscrire de force et fermer (invalider) une WebSocket connexion depuis un client connecté en fonction d'une logique de filtrage spécifique. Cela est utile dans les scénarios liés aux autorisations, par exemple lorsque vous supprimez un utilisateur d'un groupe.

L'invalidation de l'abonnement se produit en réponse à une charge utile définie dans une mutation. Nous vous recommandons de traiter les mutations utilisées pour invalider les connexions d'abonnement comme des opérations administratives dans votre API et de définir les autorisations en conséquence en limitant leur utilisation à un utilisateur administrateur, à un groupe ou à un service principal. Par exemple, en utilisant des directives d'autorisation de schéma telles que @aws_auth(cognito_groups: ["Administrators"]) ou@aws_iam. Pour plus d'informations, consultez la section Utilisation de modes d'autorisation supplémentaires.

Les filtres d'invalidation utilisent la même syntaxe et la même logique que les filtres d'abonnement améliorés. Définissez ces filtres à l'aide des utilitaires suivants :

Pour plus d'informations sur les extensions de filtrage d'invalidation, consultez la section Présentation JavaScript des résolveurs.

Utilisation de l'invalidation de l'abonnement

Pour voir comment fonctionne l'invalidation des abonnements AWS AppSync, utilisez le schéma GraphQL suivant :

type User {
  userId: ID!
  groupId: ID!
}
    
type Group {
  groupId: ID!
  name: String!
  members: [ID!]!
}

type GroupMessage {
  userId: ID!
  groupId: ID!
  message: String!
}

type Mutation {
    createGroupMessage(userId: ID!, groupId : ID!, message: String!): GroupMessage
    removeUserFromGroup(userId: ID!, groupId : ID!) : User @aws_iam
}

type Subscription {
    onGroupMessageCreated(userId: ID!, groupId : ID!): GroupMessage
        @aws_subscribe(mutations: ["createGroupMessage"])
}

type Query {
	none: String
}

Définissez un filtre d'invalidation dans le code du résolveur de removeUserFromGroup mutations :

import { extensions } from '@aws-appsync/utils';

export function request(ctx) {
	return { payload: null };
}

export function response(ctx) {
	const { userId, groupId } = ctx.args;
	extensions.invalidateSubscriptions({
		subscriptionField: 'onGroupMessageCreated',
		payload: { userId, groupId },
	});
	return { userId, groupId };
}

Lorsque la mutation est invoquée, les données définies dans l'payloadobjet sont utilisées pour annuler l'abonnement défini danssubscriptionField. Un filtre d'invalidation est également défini dans le modèle de mappage des réponses de l'onGroupMessageCreatedabonnement.

Si la extensions.invalidateSubscriptions() charge utile contient un identifiant correspondant à celui IDs du client abonné tel que défini dans le filtre, l'abonnement correspondant est désabonné. De plus, la WebSocket connexion est fermée. Définissez le code de résolution d'abonnement pour l'onGroupMessageCreatedabonnement :

import { util, extensions } from '@aws-appsync/utils';

export function request(ctx) {
	// simplfy return null for the payload
	return { payload: null };
}

export function response(ctx) {
	const filter = { groupId: { eq: ctx.args.groupId } };
	extensions.setSubscriptionFilter(util.transform.toSubscriptionFilter(filter));

	const invalidation = { groupId: { eq: ctx.args.groupId }, userId: { eq: ctx.args.userId } };
	extensions.setSubscriptionInvalidationFilter(util.transform.toSubscriptionFilter(invalidation));

	return null;
}

Notez que le gestionnaire de réponse aux abonnements peut avoir des filtres d'abonnement et des filtres d'invalidation définis en même temps.

Supposons, par exemple, que le client A abonne un nouvel utilisateur avec l'ID user-1 au groupe ayant l'ID group-1 en utilisant la demande d'abonnement suivante :

onGroupMessageCreated(userId : "user-1", groupId: :"group-1"){...}

AWS AppSync exécute le résolveur d'abonnement, qui génère des filtres d'abonnement et d'invalidation tels que définis dans le modèle de mappage de onGroupMessageCreated réponses précédent. Pour le client A, les filtres d'abonnement autorisent l'envoi de données uniquement àgroup-1, et les filtres d'invalidation sont définis pour user-1 les group-1 deux.

Supposons maintenant que le client B abonne un utilisateur avec l'ID user-2 à un groupe avec l'ID group-2 en utilisant la demande d'abonnement suivante :

onGroupMessageCreated(userId : "user-2", groupId: :"group-2"){...}

AWS AppSync exécute le résolveur d'abonnement, qui génère des filtres d'abonnement et d'invalidation. Pour le client B, les filtres d'abonnement autorisent l'envoi de données uniquement àgroup-2, et les filtres d'invalidation sont définis pour les deux user-2 etgroup-2.

Supposons ensuite qu'un nouveau message de groupe avec l'ID message-1 soit créé à l'aide d'une demande de mutation, comme dans l'exemple suivant :

createGroupMessage(id: "message-1", groupId :
      "group-1", message: "test message"){...}

Les clients abonnés correspondant aux filtres définis reçoivent automatiquement la charge utile de données suivante via WebSockets :

{
  "data": {
    "onGroupMessageCreated": {
      "id": "message-1",
      "groupId": "group-1",
      "message": "test message",
    }
  }
}

Le client A reçoit le message car les critères de filtrage correspondent au filtre d'abonnement défini. Cependant, le client B ne reçoit pas le message, car l'utilisateur n'en fait pas partiegroup-1. De plus, la demande ne correspond pas au filtre d'abonnement défini dans le résolveur d'abonnement.

Enfin, supposons que cela user-1 soit supprimé group-1 lors de l'utilisation de la demande de mutation suivante :

removeUserFromGroup(userId: "user-1", groupId : "group-1"){...}

La mutation initie une invalidation d'abonnement telle que définie dans le code du gestionnaire de réponse du extensions.invalidateSubscriptions() résolveur. AWS AppSync désabonne ensuite le client A et ferme sa WebSocket connexion. Le client B n'est pas affecté, car la charge utile d'invalidation définie dans la mutation ne correspond pas à son utilisateur ou à son groupe.

Lorsqu'une connexion est AWS AppSync invalidée, le client reçoit un message confirmant qu'il est désabonné :

{
  "message": "Subscription complete."
}

Utilisation de variables contextuelles dans les filtres d'invalidation des abonnements

Comme pour les filtres d'abonnement améliorés, vous pouvez utiliser la contextvariable de l'extension du filtre d'invalidation d'abonnement pour accéder à certaines données.

Par exemple, il est possible de configurer une adresse e-mail comme charge utile d'invalidation lors de la mutation, puis de l'associer à l'attribut e-mail ou à la réclamation d'un utilisateur abonné autorisé par les groupes d'utilisateurs Amazon Cognito ou OpenID Connect. Le filtre d'invalidation défini dans l'invalidateur extensions.setSubscriptionInvalidationFilter() d'abonnement vérifie si l'adresse e-mail définie par la extensions.invalidateSubscriptions() charge utile de la mutation correspond à l'adresse e-mail récupérée à partir du jeton JWT de l'utilisateur, déclenchant ainsi l'invalidation. context.identity.claims.email