Utilizamos SSO e, desde alguns dias atrás, alguns de nossos membros relatam não conseguir acessar suas contas com o seguinte erro:
Há um problema com sua conta. Entre em contato com o administrador do site.
Achei que isso pudesse ser devido a um problema que relatei anteriormente, então verifiquei se o endereço IP deles estava em IPs Bloqueados (Screened IPs): um deles estava… mas não todos os outros.
Após ativar o verbose sso logging, pedi que outros usuários tentassem novamente e os registros em /logs indicam que o endereço IP deles está bloqueado:
Log SSO detalhado: Endereço IP está bloqueado xxx.xxx.xxx.xxx
No entanto, verifiquei novamente e o endereço IP não aparece em IPs Bloqueados. Também verifiquei diretamente na tabela screened_ip_addresses do PostgreSQL e não há nenhuma entrada para esse endereço IP.
Estou ficando sem ideias… Existe outra seção para bloquear endereços IP que deveríamos verificar? Ou os endereços IP são adicionados aos IPs Bloqueados por um período muito curto e eu nunca os pego após o relatório (questão de algumas horas)?
Para ficar claro, nunca adicionamos IPs manualmente aos IPs Bloqueados — eles parecem ser adicionados automaticamente quando fechamos a conta de alguém via API (veja o link acima) e não conseguimos impedir que isso aconteça usando o parâmetro documentado block_ip: false.
O problema com IPs sendo adicionados aos IPs Filtrados é separado do que estou tentando relatar aqui. Estamos vendo membros não bloqueados pelos IPs Filtrados que não conseguem fazer login em suas contas via SSO, supostamente porque o ‘endereço IP está bloqueado’.
Existem outros locais além dos IPs Filtrados que podem bloquear endereços IP que eu deveria investigar?
Parece que você está chamando a função “excluir como spammer”, que bloqueia automaticamente o IP e o endereço de e-mail. Acredito que você deva revisar esse código. Você deseja a “exclusão simples” conforme a interface do usuário, não a “exclusão como spammer”.
Isso pode ser verdade, mas a forma como estamos excluindo usuários está sendo discutida aqui.
Não tenho certeza se se trata de um problema separado, mas notei que a coluna “Correspondências” na seção de IPs Filtrados mostra 0 correspondências em todas as entradas. Analisei a exportação dessa tabela e ela confirma que todos os IPs têm 0 correspondências. No entanto, todos os dias vemos usuários sendo bloqueados por endereço IP ao tentar fazer login (via SSO).
No entanto, ao examinar os E-mails Filtrados, a maioria tem uma correspondência! E há também uma coluna de endereço de IP lá… então pensei que havia encontrado o culpado, mas nenhum dos endereços de IP que estão sendo bloqueados está listado lá também.
Isso é de há alguns minutos, extraído dos nossos /logs:
Também verifiquei os E-mails Filtrados e nem o endereço de IP nem o endereço de e-mail da conta que acabou de ser bloqueada ao tentar fazer login estão lá.
Acho que encontrei o problema aqui (no fim, o problema estava do nosso lado), mas há alguns bugs para relatar, embora essa não seja uma stack com a qual eu me sinta confortável, então espero que alguém possa dar uma olhada mais adequada.
Primeiro, a causa. Ao examinar diretamente a tabela do banco de dados screened_ip_addresses, descobri que ela estava bloqueando dois blocos inteiros que não deveria (176.59.0.0/16 e 109.252.0.0/16). Honestamente, não sei como eles foram adicionados, e as duas entradas estavam lá desde fevereiro. Existe algum botão no admin do Discourse para bloquear um bloco inteiro /16 de uma só vez!?
De qualquer forma, isso provavelmente foi o culpado pelo meu problema inicial. Ainda há alguns problemas que a equipe do Discourse pode querer investigar, pois foi isso que tornou isso especialmente difícil de resolver:
Esses intervalos bloqueados não aparecem listados em IPs filtrados por algum motivo. Tive que procurar diretamente no banco de dados para encontrá-los. Usar a busca com “176.59” ou “109.252”, no entanto, os mostra. Existe algum limite de resultados sendo aplicado em /admin/logs/screened_ip_addresses?
Na exportação, eles aparecem como 176.59.0.0 e 109.252.0.0, ou seja, não mostra nenhuma informação de bloco. Isso é verdade mesmo para os intervalos padrão (127.0.0.0/8, 10.0.0.0/8, etc) — nenhuma máscara é mostrada no arquivo de exportação.
Mesmo que essas entradas tenham estado bloqueando usuários, elas têm um valor de match_count igual a 0 e last_match_at está vazio (para toda a tabela). Isso é intencional? Provavelmente não se quer contar todas as correspondências allow, mas se os bloqueios não são contados, essas colunas parecem não ser usadas/necessárias. Ou talvez o login via SSO não esteja disparando essas correspondências?
Mais uma vez, preciso te dizer que tenho quase certeza de que você está chamando “excluir como spammer” pela API. Se houver exclusões suficientes de spammers provenientes de endereços IP relacionados, a proibição do endereço IP começa a se expandir automaticamente. Tenho bastante certeza de que é isso que você está vendo aqui.
E isso, sim. Talvez a razão pela qual sua lista de IPs filtrados seja tão grande seja porque você tem estado “excluindo como spammer” há muito tempo? Você não quer isso.
Você quer “Excluir apenas”, não “Excluir e bloquear”, mas quase tudo que você postou fornece evidências de que você está chamando “Excluir e bloquear” via API..
O problema não foi o endpoint utilizado, mas os parâmetros, pois a API espera que os booleanos sejam as strings ‘true’/‘false’, e eu não estava ciente disso.
Ainda existem alguns outros bugs mencionados acima que encontrei, mas não sei se devem ser corrigidos. Caso contrário, isso pode ser fechado. Obrigado.
