Estamos utilizando SSO para el inicio de sesión y la creación de cuentas. No existe otra forma de iniciar sesión o registrarse en nuestro foro.
Sin embargo, la lista de direcciones IP filtradas contiene decenas de direcciones IP que se agregan automáticamente cada día. ¿Es esto esperado? ¿Qué hace que una dirección IP se agregue a la lista de IPs filtradas?
La única forma que se me ocurre es cuando eliminas una cuenta y optas por el botón ‘Eliminar spammer’.
Buen punto: es cuando eliminamos una cuenta a través de la API que la dirección IP se añade a las IPs filtradas.
Sin embargo, estamos enviando la solicitud DELETE con block_ip=false. Esto es lo que muestran los registros de Rails:
Parameters: {"delete_posts"=>"1", "block_email"=>"0", "blocked_urls"=>"0", "block_ip"=>"0", "id"=>"123"}
Pero las direcciones IP se están bloqueando de todos modos, ¿quizás haya algún error en algún lugar?
Podría ser, aunque creo que no. Estoy utilizando el único endpoint para eliminar un usuario que encontré:
DELETE /admin/users/{id}.json
el cual tiene un parámetro block_ip que, por defecto, es true y que siempre configuro en false. Sin embargo, las direcciones IP siguen agregándose a las IPs filtradas.
Es posible que quieras usar Reverse engineer the Discourse API y ver exactamente qué solicitudes se envían al eliminar un usuario y presionar el botón que dice Solo eliminar
… porque puedo asegurarte que, si ves que se agregan direcciones IP a la lista de filtrados después de la eliminación, definitivamente estás eliminando al usuario como spam, es decir, el botón del medio: eliminar y bloquear.
Ya había hecho eso y el punto final de la API de eliminación es el que he estado utilizando, el mismo para ambas acciones (solo eliminar y eliminar y bloquear). La única diferencia radica en los parámetros que se utilizan con él (block_ip, block_email, …), que mencioné anteriormente.
Creo que finalmente entendí cuál era el problema con mis solicitudes: la API de Discourse espera las cadenas ‘true’ y ‘false’ en lugar de valores truthy/falsy. Fue mi culpa no haber notado esa indicación en la documentación.
Eso probablemente fue lo que causó todo este lío.
Puede que me haya adelantado. 
Tras corregir los parámetros truthy/falsy a las cadenas ‘true’/‘false’, sigo viendo que se añaden entradas a “Screened IPs” y “Screened Emails” al eliminar usuarios.
Aquí están los registros de Rails para una llamada a la 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)
Y aquí está la solicitud realizada a través de la interfaz web en lugar de llamar a la 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)
Por lo tanto, tras algunas pruebas, parece que los parámetros del punto de acceso de la API /admin/users/{id}.json se interpretan siempre como true cuando están presentes, independientemente de si realmente se establecen en ‘true’ o ‘false’.
Una vez que empecé a establecer solo los parámetros que eran ‘true’ y omitir los ‘false’, ya no se añadieron más entradas a las IPs/correos electrónicos filtrados.
¿Es este el comportamiento previsto? Eso no es lo que entiendo de la documentación.
Mientras hayas emulado el comportamiento que observas al seguir el tema Reverse engineer the Discourse API, deberías estar bien. ¿Qué llamadas a la API estás observando en el monitor de red cuando pulsas el botón “solo eliminar”?
En algunos casos, cuando el JS no pasa explícitamente false al servidor, este trata cualquier valor presente como verdadero. Es probable que esto sea lo que estás experimentando aquí.