Мы используем SSO для входа и создания учетных записей. Других способов входа или регистрации на нашем форуме нет.
Однако в списке заблокированных IP-адресов десятки записей, которые автоматически добавляются ежедневно. Это ожидаемое поведение? По каким причинам IP-адрес попадает в список заблокированных?
Единственный способ, о котором я могу подумать, — это когда вы удаляете аккаунт и выбираете кнопку «Удалить спамера».
Хорошая мысль — IP-адрес добавляется в список заблокированных (Screened IPs) именно тогда, когда мы удаляем аккаунт через API.
Однако мы отправляем запрос DELETE с параметром block_ip=false. Вот что записано в логах Rails:
Parameters: {"delete_posts"=>"1", "block_email"=>"0", "blocked_urls"=>"0", "block_ip"=>"0", "id"=>"123"}
Но IP-адреса всё равно блокируются. Возможно, где-то есть ошибка?
Возможно, хотя я так не думаю? Я использую единственный найденный мной endpoint для удаления пользователя:
DELETE /admin/users/{id}.json
У него есть параметр block_ip, который по умолчанию установлен в true, но я всегда устанавливаю его в false. Тем не менее IP-адреса всё равно добавляются в список отслеживаемых IP-адресов.
Возможно, вам стоит воспользоваться ссылкой Reverse engineer the Discourse API и посмотреть, какие именно запросы отправляются при удалении пользователя, нажав на кнопку Только удалить
… потому что я могу с уверенностью сказать: если вы видите, что IP-адреса добавляются в список заблокированных после удаления, вы точно удаляете пользователя как спамера, то есть нажимаете среднюю кнопку — удалить и заблокировать.
Я уже делал это, и конечная точка API для удаления — это та, которую я использовал, причём она одинакова для обоих действий (только удаление и удаление с блокировкой). Единственное различие заключается в используемых с ней параметрах (block_ip, block_email, …), о которых я упомянул выше.
Кажется, я наконец понял, в чём была проблема с моими запросами: API Discourse ожидает строки ‘true’ и ‘false’, а не истиные/ложные значения. Моя вина, что я не заметил об этом предупреждение в документации.
Вероятно, именно это вызывало весь этот хаос.
Возможно, я поспешил с выводами. 
После того как я исправил параметры truthy/falsy на строки ‘true’/‘false’, при удалении пользователей всё ещё добавляются записи в списки «Заблокированные IP» и «Заблокированные email-адреса».
Вот логи Rails для вызова 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)
А вот запрос, выполненный через веб-интерфейс вместо вызова 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)
Таким образом, после нескольких тестов кажется, что параметры для конечной точки API /admin/users/{id}.json всегда интерпретируются как true, если они присутствуют, независимо от того, установлены ли они фактически в ‘true’ или ‘false’?
Как только я начал передавать только параметры со значением ‘true’, пропуская те, что равны ‘false’, записи больше не добавляются в списки «Заблокированные IP» и «Заблокированные email-адреса».
Это ожидаемое поведение? Это не соответствует тому, что я понял из документации.
Пока вы эмулируете поведение, которое наблюдается при следовании теме Reverse engineer the Discourse API, у вас всё будет в порядке. Какие вызовы API вы наблюдаете в мониторе сети при нажатии кнопки «Удалить только»?
В некоторых случаях, когда JS явно не передаёт false на сервер, сервер считает любое присутствующее значение истинным. Вероятно, именно с этим вы столкнулись здесь.