Correction de l'erreur « M_FORBIDDEN : Vous n'avez pas l'autorisation » dans l'interface d'administration de Matrix Room

Vous tentez de modifier les paramètres d'une salle Matrix, de supprimer un utilisateur, de bannir quelqu'un, de modifier les permissions ou d'effectuer une autre action administrative et vous recevez M_FORBIDDEN: You do not have permissionun message d'erreur. Pour un nouvel utilisateur, ce message peut prêter à confusion car le terme « admin » peut avoir deux significations différentes dans Matrix : un administrateur de serveur contrôle le serveur principal, tandis qu'un administrateur de salle dispose des droits nécessaires au sein d'une salle spécifique. Il s'agit de systèmes de permissions distincts.

La solution la plus fiable consiste à identifier la couche d'autorisation qui a bloqué l'action avant toute modification. L'autorisation des salles Matrix repose sur des niveaux de puissance : des valeurs numériques stockées dans l'état de la salle qui déterminent qui peut inviter, exclure, bannir, masquer des messages, modifier les paramètres de la salle ou modifier les niveaux de puissance eux-mêmes. La spécification Matrix actuelle définit ces règles dans la spécification de l'API client-serveur Matrix . Synapse précise par ailleurs, dans la documentation de son API d'administration, qu'un administrateur de serveur est différent d'un administrateur de salle .

Avant de changer quoi que ce soit : connaissez les quatre valeurs essentielles.

Vous avez généralement besoin de quatre informations :

• Votre identifiant utilisateur Matrix , par exemple @alice:example.com.
• L'identifiant de la salle , par exemple !abc123:example.com. Un alias de salle tel que #team:example.comest plus facile à lire, mais de nombreuses API fonctionnent avec l'identifiant interne de la salle.
• Votre statut d'abonnement . Dans la plupart des cas, vous devez être connecté à la salle avant de pouvoir effectuer des actions de gestion de salle.
• Votre niveau de puissance et le niveau requis pour l'action .

Dans Element Web ou Desktop, l'identifiant et la version de la salle se trouvent dans les paramètres avancés. La documentation actuelle d'Element indique également que la gestion des salles se trouve dans Paramètres de la salle → Rôles et autorisations . Consultez le guide des paramètres de salle d'Element .

Étape 1 : Vérifiez que vous êtes bien connecté à la salle.

Matrix distingue plusieurs statuts d'adhésion : invité, membre, ancien membre et banni. Un utilisateur a généralement besoin de son joinstatut d'adhésion pour envoyer des événements à une salle ou l'administrer. Cela est important car un compte administrateur du serveur d'accueil peut échouer lors d'une action normale dans la salle s'il n'y participe pas.

Si vous utilisez un client Matrix comme Element, ouvrez la salle et vérifiez qu'elle apparaît bien comme une salle active à laquelle vous avez adhéré, et non comme une simple invitation ou une salle archivée. Si vous utilisez Synapse et avez besoin d'une procédure de récupération pour l'administration du serveur, Synapse propose un point d'accès administrateur permettant d'ajouter un utilisateur local à une salle. Toutefois, la documentation relative aux autorisations nécessaires pour cette opération reste disponible. Consultez la section « Administration des adhésions aux salles Synapse » .

Évitez cette erreur : ne présumez pas que la possession d’un jeton d’API d’administration Synapse confère automatiquement les mêmes privilèges au niveau de la salle. L’administration du serveur et l’administration de la salle sont deux choses distinctes.

Étape 2 : Vérifiez votre rôle et le niveau de puissance requis pour l’action.

Element présente les niveaux de pouvoir courants sous forme de rôles familiers tels que Membre, Modérateur et Administrateur. En interne, Matrix évalue des nombres plutôt que des étiquettes. La spécification Matrix recommande l'interprétation classique suivante : utilisateurs ordinaires en dessous du seuil d'événement d'état, modérateurs au-dessus de ce seuil et administrateurs au niveau requis ou supérieur pour la modification m.room.power_levels. Les salles utilisent généralement 0 pour les membres, 50 pour les modérateurs et 100 pour les administrateurs, mais ces valeurs peuvent être personnalisées.

Ouvrez les paramètres de la salle → Rôles et permissions . Vérifiez votre rôle et l'action que vous souhaitez effectuer. La documentation actuelle d'Element répertorie les actions courantes telles que la modification des paramètres, la suppression ou le bannissement d'utilisateurs, la modification de la visibilité de l'historique et la modification des permissions, chacune nécessitant un niveau d'autorisation spécifique.

Par exemple, supposons que votre compte ait un niveau de puissance de 50 et que la salle exige un niveau de 100 pour modifier les permissions. Vous pouvez toujours être modérateur et effectuer certaines tâches administratives, mais toute tentative de modification du modèle de permissions renverra une erreur M_FORBIDDEN.

Étape 3 : Vérifiez l’utilisateur cible ainsi que votre propre puissance

C'est l'une des règles de la Matrice les plus faciles à oublier. Pour les exclusions et les bannissements, atteindre le seuil d'action ne suffit pas toujours. Les règles d'autorisation de la Matrice exigent également que l'utilisateur ciblé ait un niveau de puissance inférieur à celui de la personne effectuant l'action.

Exemple : votre compte est de niveau 50, le kickseuil d’exclusion du salon est de 50 et un autre modérateur est également de niveau 50. Vous atteignez le seuil d’exclusion, mais vous ne pouvez toujours pas exclure le modérateur de même niveau. Les règles d’autorisation refusent l’opération car la cible n’est pas d’un niveau inférieur au vôtre.

Ce même principe explique de nombreux échecs de modération déroutants. Un administrateur de salle doit examiner les deux aspects de la comparaison :

• Votre niveau de puissance actuel.
• Le kickseuil requis ban.
• Niveau de puissance actuel de l'utilisateur cible.

Si la cible est un administrateur de même niveau, un autre administrateur de même niveau ne peut généralement pas simplement supprimer les privilèges de cet utilisateur. La documentation avancée d'Element sur la gestion des salles indique clairement que les administrateurs ne peuvent pas supprimer les autorisations d'administrateur d'autres administrateurs dans le cadre du flux de travail client standard. Voir Gestion avancée des salles dans Element .

Étape 4 : Utiliser un administrateur de salle existant lorsqu’il y en a un de disponible.

La solution la plus simple est généralement d'ordre organisationnel plutôt que technique. Si un autre administrateur de salle est actif et dispose des autorisations suffisantes, demandez-lui de promouvoir votre compte via Paramètres de la salle → Rôles et autorisations .

Cette méthode est préférable à la modification manuelle de l'état de la salle, car le client affiche le modèle de rôle actuel et applique les mêmes règles d'autorisation que tout autre client Matrix. Après la promotion, réessayez l'action initiale.

Si le problème persiste, comparez l'action exacte avec le seuil d'autorisation plutôt que de supposer que « Administrateur » signifie que toutes les actions sont automatiquement autorisées. Les événements de niveau d'autorisation personnalisés peuvent attribuer des seuils inhabituels à certains types d'événements.

Étape 5 : S’il ne reste plus d’administrateur de salle utilisable, récupérez-le via Synapse.

Si vous gérez le serveur Synapse et qu'une salle est restée sans administrateur actif, utilisez les API de récupération prises en charge par Synapse au lieu de modifier la base de données ou de créer de faux événements de salle. Synapse fournit une API de création d'administrateur de salle :

POST /_synapse/admin/v1/rooms/<room_id_or_alias>/make_room_admin

{
  "user_id": "@alice:example.com"
}

Authentifiez cette requête avec le jeton d'accès d'un administrateur de serveur Synapse . La documentation officielle de l'API d'administration des salles est disponible sur la page API d'administration des salles Synapse . Ce point de terminaison octroie à l'utilisateur local sélectionné les droits d'accès les plus élevés disponibles pour un utilisateur local dans cette salle ; si nécessaire et possible, il peut inviter cet utilisateur au préalable.

Après l'appel de récupération, rejoignez ou rouvrez la salle avec le compte promu et réessayez l'action dans le client Matrix.

Cas particulier : version 12 et ultérieures de la salle

La version 12 de Matrix Room modifie la représentation des créateurs. Le créateur possède un niveau de puissance illimité et immuable et n'apparaît pas comme un utilisateur ordinaire sur la userscarte m.room.power_levels. Il ne peut pas être rétrogradé par un événement de niveau de puissance classique. Ce comportement est documenté dans la spécification de la version 12 de Matrix Room .

Cela signifie qu'une technique de dépannage copiée d'une version antérieure de la salle peut ne pas s'appliquer telle quelle à une salle de version 12. Vérifiez la version de la salle avant d'entreprendre une récupération avancée ou des modifications des niveaux de puissance.

Comment inspecter directement les niveaux de puissance

Pour un dépannage avancé, l'événement d'état de salle pertinent est m.room.power_levels. Il contient des champs tels que :

{
  "users_default": 0,
  "state_default": 50,
  "invite": 0,
  "kick": 50,
  "ban": 50,
  "redact": 50,
  "users": {
    "@alice:example.com": 100,
    "@bob:example.com": 50
  }
}

Si votre compte n'est pas répertorié users, son niveau est généralement ramené à users_default0. Pour la plupart des salles, cela correspond à 0. Certains types d'événements peuvent également modifier l'état général ou les seuils de messages via la eventscarte.

Ne remplacez pas l'intégralité de l'événement de niveau de puissance par un petit objet partiel, sauf si vous savez précisément ce que le client ou l'API conservera. L'état du niveau de puissance peut contenir plusieurs champs importants ; les supprimer accidentellement peut modifier davantage d'autorisations que prévu.

Ce qu'il ne faut pas faire

• Ne promouvez pas un compte Synapse au rang d'administrateur de serveur uniquement pour résoudre un problème de rôle dans une salle. Utilisez le minimum de privilèges nécessaires.
• Ne modifiez pas les lignes de la base de données Synapse pour changer les niveaux de puissance des salles. L'autorisation d'accès aux salles est représentée par des événements de salle signés, et non par un simple indicateur utilisateur dans la base de données.
• Ne redémarrez pas Synapse comme solution de routine M_FORBIDDEN. Les échecs d'autorisation sont généralement dus à des décisions déterministes concernant l'état de la salle, et non à des problèmes de processus obsolètes.
• Ne présumez pas que la suppression du cache client modifie les autorisations. C'est le serveur d'accueil qui applique la règle d'autorisation.
• Ne divulguez pas les jetons d'accès dans l'historique de navigation, les captures d'écran, les tickets d'assistance ou les URL. Privilégiez l'utilisation d'un Authorization: Bearer ...en-tête lors de l'utilisation d'API.

Tableau de diagnostic rapide

Vérification finale

La correction est terminée lorsque le compte qui doit administrer la salle est connecté, dispose d'un niveau de puissance suffisant pour l'action prévue et peut l'exécuter sans M_FORBIDDENerreur 403. Pour les actions de modération, vérifiez également que le niveau de puissance de l'utilisateur cible est inférieur à celui requis par les règles d'autorisation Matrix.

Pour un nouvel administrateur Matrix, le modèle mental le plus utile est simple : il faut d’abord identifier s’il s’agit d’ une autorisation de serveur principal ou d’une autorisation de salle . Ensuite, il faut vérifier les membres, son niveau d’autorisation, le seuil d’action et le niveau de l’utilisateur concerné. Cette procédure permet de résoudre la plupart des erreurs d’autorisation sans avoir à modifier inutilement le serveur.