Discourse Events expose un certain nombre de points d’accès REST sous /discourse-post-event/..., mais lors de la création d’une clé d’API administrateur avec une portée Granulaire, il ne semble pas exister de portée spécifique aux Événements.
Il existe déjà une portée de clé d’API utilisateur discourse-calendar:events_calendar pour les flux d’abonnement au calendrier, tels que le point d’accès ICS. Cette demande porte donc spécifiquement sur les clés d’API administrateur/serveur-à-serveur REST granulaires, et non sur les clés d’abonnement au calendrier.
Cas d’utilisation
Une intégration externe peut n’avoir besoin que d’interroger Discourse Events - par exemple, pour vérifier si un événement existe ou récupérer des informations sur un événement.
À l’heure actuelle, il ne semble pas y avoir de moyen d’émettre une clé d’API administrateur restreinte spécifiquement aux points d’accès REST de Discourse Events. Cela signifie qu’une intégration peut se voir accorder un accès à une portée d’API plus large que ce qu’elle nécessite réellement.
Il serait utile que discourse-events enregistre des portées de clés d’API granulaires pour ses routes REST, afin que les intégrations puissent respecter le principe du moindre privilège.
Idéalement, ces portées pourraient distinguer les opérations, par exemple :
- lecture/interrogation des événements
- gestion des événements
- gestion des invités aux événements
Même une portée de lecture seule pour les Événements serait utile.
Un rapport récent connexe a également noté que, lors de l’essai de la portée de clé d’API Granulaire, aucune restriction apparente n’était disponible pour les points d’accès Événements.
Les routes Événements existantes conservent l’espace de noms d’URL /discourse-post-event/... pour des raisons de compatibilité, bien que le plugin lui-même soit désormais nommé discourse-events. Je ne pense donc pas que la portée doive nécessairement utiliser l’ancien nom du plugin.
Je n’ai actuellement pas suffisamment de temps pour préparer une demande de pull (PR) à ce sujet, mais je souhaitais le soumettre en tant que demande de fonctionnalité, au cas où cela serait également utile à d’autres intégrations ou s’il s’agissait d’une modification pr-welcome appropriée.