We use SSO, and since a few days, some of our members are reporting being unable to access their account with the error:
There is a problem with your account. Please contact the site’s administrator
I thought this could be due to an issue I previously reported, so I checked if their IP address was on the Screened IPs: one of them was… but not of all the others.
After activating verbose sso logging, I asked other users to try again and the /logs says their IP address is blocked:
Verbose SSO log: IP address is blocked xxx.xxx.xxx.xxx
However, I have double-checked, and the IP address does not show under Screened IPs. I also checked directly on the PostgreSQL screened_ip_addresses table and no entry for the IP address.
I’m running out of ideas… Is there another section to block IP addresses that we should look into? Or are IP addresses added to the Screened IPs for a very short time and I never catch them after the report (a matter of a few hours)?
To be clear, we never add any IPs do the Screened IPs — they seem to be added automatically when we close someone’s account through the API (see link above) and we haven’t been able to stop this from happening using the documented block_ip: false parameter.
The issue with IPs being added to Screened IPs is a separate one from what I’m trying to report here. We are seeing members not blocked by the Screened IPs that can’t login into their account via SSO, supposedly because IP address is blocked.
Are there more places other than Screened IPs that may block IP addresses that I should be looking into?
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 may be true, but how we are deleting users is being discussed here.
Not sure if this is a separate issue, but I noticed that the Matches column on Screened IPs section shows 0 matches in all entries. I looked at the export of that table and it confirms that all IPs have 0 matches. Yet, every day we are seeing users being blocked by IP address from logging (via SSO).
However, looking at the Screened Emails, most have a match! And, there’s an IP address column in there too… so I thought I had found the culprit, however, none of the IP addresses that are being blocked is listed there either.
I also looked into the Screened Emails and neither the IP address or the Email address of the account that just got blocked from signing in are in there.
I think I found the issue here (in the end the issue was on our side) but there’s some bugs to report, although this is not a stack I’m comfortable with, so hopefully someone can take a better look.
First, the cause. Looking at the screened_ip_addresses database table directly, I found it was blocking two entire blocks that it shouldn’t (176.59.0.0/16 and 109.252.0.0/16). I honestly don’t know they got added and the two entries were there since February. Is there any button in the Discourse admin to block an entire /16 block in one go!?
Anyhow, that is likely to be the culprit for my initial problem. There’s still some issues that the Discourse team may want to look into as that was what made this specially hard to address:
Those blocked ranges do not appear list on the Screened IPs for some reason. I had to look directly in the database to find them. Using the search with “176.59” or “109.252” however shows them. Is there a limit of results being applied on /admin/logs/screened_ip_addresses?
On the Export, they show as 176.59.0.0 and 109.252.0.0, ie, it doesn’t show any block information. This is true even for the default ranges (127.0.0.0/8, 10.0.0.0/8, etc) — no mask is shown on the Export file.
Even though these entries have been blocking users, they have a match_count value of 0 and last_match_at is empty (for the whole table). Is this intended? Probably one doesn’t want to count all the allow matches, but if the blocks are not counted, these columns don’t seem to be used/needed. Or perhaps the login through SSO isn’t triggering those matches?
Yet again, I gotta tell you that I’m pretty sure you are calling “delete as spammer” from the API. If there are enough spammer deletions from related IP addresses, the IP address ban starts getting wider automatically. I am fairly confident that’s what you’re seeing here.
And this, yes. Perhaps the reason your screened IP list is so large, is because you’ve been “deleting as spammer” for a long time now? You don’t want that.
You want “Delete only”, not “Delete and block”, but almost everything you’ve posted provides evidence that you are calling “Delete and block” via the API…
