Corrigir "M_FORBIDDEN: Você não tem permissão" no painel de administração do Matrix.

Você tenta alterar uma configuração de sala no Matrix, remover um usuário, banir alguém, editar permissões ou executar outra ação administrativa e recebe M_FORBIDDEN: You do not have permissiona mensagem "admin". Para um iniciante, essa mensagem pode ser confusa, pois "admin" pode ter dois significados diferentes no Matrix: um administrador de servidor controla o servidor principal, enquanto um administrador de sala tem privilégios suficientes dentro de uma sala específica. São sistemas de permissões distintos.

A solução confiável é identificar qual camada de permissão bloqueou a ação antes de alterar qualquer coisa. A autorização de salas no Matrix é baseada em níveis de poder : números armazenados no estado da sala que determinam quem pode convidar, expulsar, banir, ocultar mensagens, alterar as configurações da sala ou editar os próprios níveis de poder. A especificação atual do Matrix define essas regras na especificação da API Cliente-Servidor do Matrix . O Synapse documenta separadamente que um administrador de servidor é diferente de um administrador de sala na documentação da API de Administração do Synapse .

Antes de mudar qualquer coisa: conheça os quatro valores que importam.

Geralmente você precisa de quatro informações:

• Seu ID de usuário do Matrix , por exemplo @alice:example.com.
• O ID da sala , por exemplo !abc123:example.com. Um alias de sala, como `room_`, #team:example.comé mais fácil de ler, mas muitas APIs operam com o ID interno da sala.
• Seu status de membro . Na maioria dos casos, você precisa estar conectado à sala antes de poder realizar ações de gerenciamento da sala.
• Seu nível de poder e o nível necessário para a ação .

No Element Web ou Desktop, o ID e a versão da sala podem ser encontrados em Configurações da Sala, na seção Avançado. A documentação atual do Element também inclui o gerenciamento de salas em Configurações da Sala → Funções e Permissões . Consulte o guia de configurações de sala do Element .

Passo 1: Confirme se você realmente está conectado à sala.

O Matrix distingue vários estados de associação, incluindo convidado, entrou, saiu e banido. Um usuário geralmente precisa de um joinestado de associação para enviar eventos da sala ou administrá-la. Isso é importante porque uma conta de administrador do servidor doméstico ainda pode falhar em uma ação normal da sala se essa conta não estiver participando dela.

Se você estiver usando um cliente Matrix, como o Element, abra a sala e confirme se ela aparece como uma sala ativa à qual você se juntou, e não apenas como um convite ou uma sala antiga. Se você utiliza o Synapse e precisa de um caminho de recuperação para administradores do servidor, o Synapse oferece um endpoint administrativo para adicionar um usuário local a uma sala, mas ainda documenta os requisitos de permissão para essa operação. Consulte Administração de membros de salas do Synapse .

Evite este erro: não presuma que possuir um token da API de administrador do Synapse automaticamente concede os mesmos privilégios de nível de sala à sua conta. A administração do servidor e a administração da sala são intencionalmente distintas.

Passo 2: Verifique sua função e o nível de poder necessário para a ação.

O Element apresenta níveis de poder comuns como funções familiares, como Membro, Moderador e Administrador. Internamente, o Matrix avalia números em vez de rótulos. A especificação do Matrix recomenda a interpretação familiar de usuários comuns abaixo do limite de evento de estado, moderadores acima desse limite e administradores no nível ou acima do necessário para editar m.room.power_levels. Salas típicas geralmente usam 0 para membros, 50 para moderadores e 100 para administradores, mas uma sala pode personalizar esses valores.

Acesse Configurações da Sala → Funções e Permissões . Verifique sua função e a ação exata que você está tentando realizar. A documentação atual do Element lista ações comuns, como alterar configurações, remover usuários, banir usuários, alterar a visibilidade do histórico e alterar permissões, cada uma com seu próprio nível de privilégios necessário.

Por exemplo, suponha que sua conta tenha nível de poder 50 e a sala exija nível 100 para alterar as permissões. Você ainda poderá ser moderador e executar algumas tarefas administrativas, mas tentar editar o modelo de permissão retornará corretamente um erro M_FORBIDDEN.

Etapa 3: Verifique o usuário alvo, bem como seu próprio poder.

Esta é uma das regras do Matrix mais fáceis de ignorar. Para operações de expulsão e banimento, atingir o limite de ações nem sempre é suficiente. As regras de autorização do Matrix também exigem que o usuário alvo tenha um nível de poder inferior ao da pessoa que realiza a ação.

Exemplo: sua conta tem nível 50, o kicklimite da sala é 50 e outro moderador também tem nível 50. Você atende ao limite para expulsar alguém, mas ainda assim não consegue expulsar o moderador de nível igual ao seu. As regras de autorização rejeitam a operação porque o alvo não está abaixo do seu nível.

Esse mesmo princípio explica muitas falhas confusas de moderação. Um administrador de sala deve analisar os dois lados da comparação:

• Seu nível de energia atual.
• O requisito kickou banlimite.
• O nível de energia atual do usuário alvo.

Se o alvo for um administrador de nível igual, outro administrador de nível igual normalmente não pode simplesmente remover os privilégios desse usuário. A documentação de gerenciamento avançado de salas do Element alerta explicitamente que os administradores não podem remover permissões administrativas de outros administradores no fluxo de trabalho padrão do cliente. Consulte Gerenciamento avançado de salas do Element .

Passo 4: Utilize um administrador de sala existente, quando houver um disponível.

A solução mais simples geralmente é organizacional, e não técnica. Se houver outro administrador de sala ativo e com autoridade suficiente, peça a ele para promover sua conta em Configurações da Sala → Funções e Permissões .

Isso é preferível à manipulação manual do estado da sala, pois o cliente exibe o modelo de função atual e aplica as mesmas regras de autorização que qualquer outro cliente Matrix. Após a promoção, tente novamente a ação original.

Se ainda assim falhar, compare a ação exata com o limite de permissão, em vez de presumir que "Administrador" significa que todas as ações são permitidas automaticamente. Eventos de nível de poder personalizados podem atribuir limites incomuns a tipos de evento específicos.

Passo 5: Se não houver mais administradores de sala utilizáveis, recupere-os através do Synapse.

Se você opera o servidor doméstico Synapse e uma sala ficou sem um administrador ativo, use as APIs de recuperação suportadas pelo Synapse em vez de editar o banco de dados ou criar eventos falsos na sala. O Synapse fornece uma API para tornar uma sala administradora :

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

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

Autentique essa solicitação com o token de acesso de um administrador do servidor Synapse . A documentação oficial da API de administração de salas está disponível em API de Administração de Salas do Synapse . O endpoint concede ao usuário local escolhido o maior privilégio disponível para um usuário local naquela sala; se necessário e possível, ele pode convidar esse usuário primeiro.

Após a chamada de recuperação, entre ou reabra a sala com a conta promovida e tente novamente a ação no cliente Matrix.

Caso especial: versão 12 e posteriores da sala.

A versão 12 da sala Matrix altera a forma como os criadores são representados. O criador possui um nível de poder efetivamente ilimitado e imutável, e não é listado como um usuário comum no usersmapa m.room.power_levels. O criador não pode ser rebaixado por meio de um evento normal de mudança de nível de poder. Esse comportamento está documentado na especificação da versão 12 da sala Matrix .

Isso significa que uma técnica de solução de problemas copiada de uma versão anterior da sala pode não se aplicar sem alterações a uma sala da versão 12. Verifique a versão da sala antes de tentar a recuperação avançada ou edições de nível de energia.

Como inspecionar os níveis de energia diretamente

Para resolução de problemas avançados, o evento de estado da sala relevante é m.room.power_levels. Ele contém campos como:

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

Se sua conta não estiver listada em users, seu nível normalmente será definido como users_default. Para a maioria das salas, isso significa 0. Tipos de eventos específicos também podem substituir o estado geral ou os limites de mensagens por meio do eventsmapa.

Não substitua todo o evento de nível de poder por um pequeno objeto parcial, a menos que você saiba exatamente o que o cliente ou a API irá preservar. O estado do nível de poder pode conter vários campos importantes e excluí-los acidentalmente pode alterar mais permissões do que o pretendido.

O que não fazer

• Não promova uma conta Synapse a administrador do servidor apenas para resolver um problema comum de atribuição de funções em salas. Use o mínimo de privilégios necessário.
• Não edite as linhas do banco de dados Synapse para alterar os níveis de potência da sala. A autorização da sala é representada por eventos de sala assinados, e não simplesmente por um indicador de usuário no banco de dados.
• Não reinicie o Synapse como solução de rotina para problemas de autorização M_FORBIDDEN. Falhas de autorização geralmente são decisões determinísticas do estado da sala, e não problemas de processos obsoletos.
• Não presuma que limpar o cache do cliente altera as permissões. O servidor doméstico impõe a regra de autorização.
• Não exponha tokens de acesso no histórico do shell, capturas de tela, tickets de suporte ou URLs. Prefira um Authorization: Bearer ...cabeçalho ao usar APIs.

Tabela de diagnóstico rápido

Verificação final

A correção estará completa quando a conta que precisa administrar a sala estiver conectada, tiver um nível de privilégios suficientemente alto para a ação desejada e puder executá-la sem receber uma M_FORBIDDENresposta 403. Para ações de moderação, verifique também se o nível de privilégios do usuário em questão é menor do que o exigido pelas regras de autorização do Matrix.

Para um novo administrador do Matrix, o modelo mental mais útil é simples: primeiro, identifique se você está lidando com autoridade de servidor doméstico ou autoridade de sala . Em seguida, verifique a associação, seu nível de poder, o limite de ação e o nível do usuário alvo. Essa sequência resolve a maioria dos erros de permissão sem alterações desnecessárias no servidor.