We are using SSO for login and account creation. There’s no other way to login or signing up on our forum. However, the list of screened IPs has dozens of IP addresses which are being added automatically on a daily basis. Is this expected? What makes an IP address get added to the Screened IPs list?

Good point — it’s when we remove an account through the API that the IP is being added to the Screened IPs. However, we are issuing the DELETE request using block_ip=false. This is from rails logs: Parameters: {"delete_posts"=>"1", "block_email"=>"0", "blocked_urls"=>"0", "block_ip"=>"0", "id"=>"123"} But the IPs are being blocked nonetheless, so perhaps there’s a bug somewhere?

[image]Can't SSO due to blocked IP addresses It sounds like you are calling the “delete as spammer” function, which will automatically blocklist the IP and email address. I think you should revisit that code. You want “plain delete” per the UI, not “delete as spammer”. That could be, although I think not? I’m using the only delete a user endpoint I found: DELETE /admin/users/{id}.json which does have a block_ip parameter defaulting to true and that I always set to false. IPs are being added to Screened IPs nonetheless.

You may want to use Reverse engineer the Discourse API and see exactly what requests are sent when you delete a user, and pressing the button that says Delete only [image] … because I can tell you for a fact that if you are seeing IPs get added to the screened list after deletion, you are absolutely deleting the user as a spammer, e.g. the middle button – delete and block.

I had already done that and the deleting API endpoint is the one I have been using, which the same one for both actions (delete only and delete&block) — the only difference is on the parameters that are used with it (block_ip, block_email, …) that I mentioned aboved. [image] mentalstring: However, we are issuing the DELETE request using block_ip=false . This is from rails logs: Parameters: {"delete_posts"=>"1", "block_email"=>"0", "blocked_urls"=>"0", "block_ip"=>"0", "id"=>"123"} I think I finally got around what was the issue with my requests: Discourse’s API wants the strings ‘true’ and ‘false’ instead truthy/falsy values. My bad for not spotting the notice about that on the docs. That was probably what has been causing all this mess.

I might have spoken too soon. :disappointed_face: Having corrected the truthy/falsy parameters to ‘true’/‘false’ strings, I still see entries being added to Screened IPs and Screened Emails upon deleting users. Here’s the rails logs for a API call: 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) And here’s the request when done through the web interface instead of calling the 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) So, after some tests, it seems that the parameters for the API endpoint /admin/users/{id}.json are always interpreted as true when they are present, regardless whether they are actually being set to ‘true’ or ‘false’? Once I started only setting the parameters that were ‘true’, and skipping the ‘false’ ones, then no more entries are being added to the Screened IPs/emails. Is this the intended behavior? That’s not what I understand from the docs.

As long as you’ve emulated the behavior that you observe when you follow the Reverse engineer the Discourse API topic, you should be OK. What API calls are you observing in the network monitor when you push the “delete only” button?

In some cases, when the JS isn’t explicitly passing false to the server, the server treats any present value as true. This is likely what you’re encountering here.

SSO and Screened IPs

Product Support SSO

codinghorror (Jeff Atwood) December 9, 2020, 6:26pm 2

The only way I can think of is when you delete an account and opt for the “delete spammer” button.

Topic		Replies	Views
How to delete user accounts via API without IP blocking SSO rest-api	10	457	May 15, 2025
Can't SSO due to blocked IP addresses SSO rest-api	7	2126	June 8, 2021
Does SSO make use of Screened IP Addresses to block registrations? SSO	7	1000	September 29, 2020
BAD CSRF Response When Trying to Delete User by API Product Support	5	1086	August 1, 2018
Unable to log into my discourse - "You can't log in as xxx from that IP address." Product Support	5	3388	April 3, 2015

SSO and Screened IPs

Related topics