Estamos utilizando SSO para login e criação de contas. Não há outra forma de fazer login ou se cadastrar em nosso fórum.
No entanto, a lista de IPs filtrados contém dezenas de endereços IP que são adicionados automaticamente diariamente. Isso é esperado? O que faz com que um endereço IP seja adicionado à lista de IPs filtrados?
A única forma que consigo pensar é quando você exclui uma conta e clica no botão “Excluir spammer”.
Bom ponto — é quando removemos uma conta via API que o IP é adicionado à lista de IPs bloqueados.
No entanto, estamos enviando a solicitação DELETE com block_ip=false. Isso é dos logs do Rails:
Parameters: {"delete_posts"=>"1", "block_email"=>"0", "blocked_urls"=>"0", "block_ip"=>"0", "id"=>"123"}
Mas os IPs estão sendo bloqueados de qualquer forma, então talvez haja algum bug em algum lugar?
Pode ser, embora eu ache que não? Estou usando o único endpoint excluir um usuário que encontrei:
DELETE /admin/users/{id}.json
que possui um parâmetro block_ip com valor padrão true e que eu sempre defino como false. Mesmo assim, os IPs estão sendo adicionados aos IPs filtrados.
Você pode querer usar Reverse engineer the Discourse API e ver exatamente quais solicitações são enviadas ao excluir um usuário e pressionar o botão que diz Excluir apenas
… porque posso afirmar com certeza que, se você estiver vendo IPs serem adicionados à lista de bloqueados após a exclusão, você está absolutamente excluindo o usuário como spammer, ou seja, o botão do meio — excluir e bloquear.
Já havia feito isso, e o endpoint da API para exclusão é o mesmo que tenho usado para ambas as ações (apenas excluir e excluir e bloquear) — a única diferença está nos parâmetros utilizados com ele (block_ip, block_email, …), que mencionei acima.
Acho que finalmente descobri qual era o problema com minhas solicitações: a API do Discourse espera as strings ‘true’ e ‘false’ em vez de valores truthy/falsy. Minha culpa por não ter notado essa observação na documentação.
Isso provavelmente foi o que causou toda essa confusão.
Talvez eu tenha falado cedo demais. 
Após corrigir os parâmetros truthy/falsy para as strings ‘true’/‘false’, ainda vejo entradas sendo adicionadas em IPs Filtrados e E-mails Filtrados ao excluir usuários.
Aqui estão os logs do Rails para uma chamada de API:
Started DELETE "/admin/users/9553.json" for 123.123.123.123 at 2021-06-10 00:01:21 +0000
Processing by Admin::UsersController#destroy as JSON
Parameters: {"delete_posts"=>"false", "block_email"=>"false", "blocked_urls"=>"false", "block_ip"=>"false", "id"=>"9553"}
Can't verify CSRF token authenticity.
Rendering text template
Rendered text template (Duration: 0.0ms | Allocations: 1)
Completed 418 in 8ms (Views: 1.4ms | ActiveRecord: 0.0ms | Allocations: 2301)
E aqui está a solicitação quando feita pela interface web em vez de chamar a API:
Started DELETE "/admin/users/49.json" for 123.123.123.123 at 2021-06-10 08:24:47 +0000
Processing by Admin::UsersController#destroy as JSON
Parameters: {"context"=>"/admin/users/49/XXX", "delete_posts"=>"true", "id"=>"49"}
Rendered text template (Duration: 0.0ms | Allocations: 1)
Completed 418 in 23ms (Views: 4.7ms | ActiveRecord: 0.0ms | Allocations: 1778)
Portanto, após alguns testes, parece que os parâmetros para o endpoint da API /admin/users/{id}.json são sempre interpretados como verdadeiros quando estão presentes, independentemente de estarem realmente definidos como ‘true’ ou ‘false’?
Assim que comecei a definir apenas os parâmetros que eram ‘true’, ignorando os ‘false’, nenhuma nova entrada foi mais adicionada aos IPs/E-mails Filtrados.
Esse é o comportamento esperado? Não é isso que entendo da documentação.
Desde que você tenha emulado o comportamento que observa ao seguir o tópico Reverse engineer the Discourse API, você estará bem. Quais chamadas de API você está observando no monitor de rede ao clicar no botão “apenas excluir”?
Em alguns casos, quando o JS não está passando explicitamente false para o servidor, o servidor trata qualquer valor presente como verdadeiro. Isso provavelmente é o que você está encontrando aqui.