Невозможно войти через SSO из-за заблокированных IP-адресов

Поддержка SSO
6

Я думаю, что нашел проблему (в итоге она оказалась на нашей стороне), но есть несколько багов, о которых стоит сообщить. Хотя этот стек технологий мне не очень хорошо знаком, поэтому надеюсь, что кто-то сможет взглянуть внимательнее.

Во-первых, причина. При прямом просмотре таблицы базы данных screened_ip_addresses я обнаружил, что она блокирует два целых блока, которые не должна (176.59.0.0/16 и 109.252.0.0/16). Честно говоря, не знаю, как они туда попали, и эти две записи существовали еще с февраля. Есть ли в админ-панели Discourse кнопка для блокировки целого блока /16 за один раз!?

В любом случае, это, скорее всего, и стало причиной моей первоначальной проблемы. Однако есть еще несколько вопросов, которые команде Discourse, возможно, стоит рассмотреть, так как именно они сделали решение этой задачи особенно сложным:

  • Эти заблокированные диапазоны по какой-то причине не отображаются в списке Screened IPs. Мне пришлось искать их напрямую в базе данных. Однако поиск по “176.59” или “109.252” их показывает. Неужели к /admin/logs/screened_ip_addresses применяется ограничение на количество результатов?

  • При экспорте они отображаются как 176.59.0.0 и 109.252.0.0, то есть информация о блоке отсутствует. Это верно даже для стандартных диапазонов (127.0.0.0/8, 10.0.0.0/8 и т. д.) — в файле экспорта маска не показывается.

  • Несмотря на то, что эти записи блокируют пользователей, у них значение match_count равно 0, а last_match_at пустое (для всей таблицы). Это намеренно? Вероятно, не нужно подсчитывать все совпадения allow, но если блоки не учитываются, то эти колонки, кажется, не используются и не нужны. Или, возможно, вход через SSO не вызывает эти совпадения?