Endpoint da API users/by-external/ falhando com cabeçalhos de autorização, funciona sem

Bug
1

A partir de 24 de março, parece ter havido uma mudança na forma como a API do Discourse responde às solicitações.

Nenhuma alteração de código foi feita do nosso lado, e a Api-Key ainda é válida, mas um de nossos serviços de backend que tenta obter informações do usuário começou a falhar ao acessar o endpoint users/by-external/{id}.json.

Enviamos os cabeçalhos Api-Key e Api-Username com essas solicitações, que deveriam ser obrigatórios, de acordo com a documentação. Essas solicitações funcionaram bem por anos.

Agora, todas as solicitações feitas a este endpoint falham com um 403 e o corpo da resposta:

{
    "errors": [
        "Você não tem permissão para visualizar o recurso solicitado."
    ],
    "error_type": "invalid_access"
}

Isso também acontece se eu tentar solicitar /u/{username}.json.

Surpreendentemente, quando NÃO envio os cabeçalhos, essas solicitações que, de acordo com a documentação, exigem esses cabeçalhos de autenticação, na verdade respondem com os dados solicitados, como se estivessem autenticadas.

Também tentei enviar uma Api-Key incorreta, e a resposta é uma mensagem ligeiramente diferente:

{
    "errors": [
        "Você não tem permissão para visualizar o recurso solicitado. O nome de usuário ou a chave da API é inválido."
    ],
    "error_type": "invalid_access"
}

Isso me diz que a chave está sendo aceita, mas relata erroneamente que não concede acesso ao recurso, enquanto concede acesso total às solicitações não autenticadas.

Também acabei de testar com uma Api-Key totalmente nova com opções de todos os usuários / globais, e obtenho os mesmos resultados.

4 curtidas
10

Após trabalhar nisso com @Tim_Scaffidi, percebemos que o usuário passado para Api-Username havia sido desativado automaticamente por SiteSetting.invalidate_inactive_admin_email_after_days. Provavelmente há um bug relacionado a essa configuração, onde chamadas de API feitas por um usuário não estão atualizando a atividade de “login” desse usuário.

7 curtidas
15

Investiguei isso novamente para ver se havia algum código que deveria ser alterado para melhorar as coisas, mas como o problema ocorreu apenas porque uma chave de API “Todos os Usuários” estava sendo usada, não acho que devamos alterar nada em termos de código. A melhor opção para evitar a desativação do usuário é usar uma chave de API “Usuário Único” para que possamos verificar o last_used_at no registro da chave de API em vez de tentar verificar o last_seen_at no registro do usuário.

1 curtida