SSO and Screened IPs

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?

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

1 Like

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?

1 Like

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 How to 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

… 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.

1 Like

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.

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.

1 Like