Can't SSO due to blocked IP addresses

sso
6

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?

2 Likes