Мы используем SSO, и в течение последних нескольких дней некоторые из наших пользователей сообщают о невозможности войти в свою учётную запись с ошибкой:
Возникла проблема с вашей учётной записью. Пожалуйста, обратитесь к администратору сайта
Я предположил, что это может быть связано с проблемой, о которой я ранее сообщал, поэтому проверил, находится ли IP-адрес пользователя в списке заблокированных IP (Screened IPs): один из них там был… но не все остальные.
После включения verbose sso logging я попросил других пользователей попробовать снова, и в логах (/logs) указано, что их IP-адрес заблокирован:
Verbose SSO log: IP address is blocked xxx.xxx.xxx.xxx
Однако я дважды проверил, и этот IP-адрес не отображается в списке Screened IPs. Я также проверил напрямую таблицу PostgreSQL screened_ip_addresses, и там нет записи для этого IP-адреса.
У меня заканчиваются идеи… Есть ли ещё какой-то раздел для блокировки IP-адресов, на который нам стоит обратить внимание? Или IP-адреса добавляются в список Screened IPs лишь на очень короткое время, и я не успеваю их заметить после отчёта (в течение нескольких часов)?
Для ясности: мы никогда не добавляем IP-адреса в список Screened IPs вручную — они, похоже, добавляются автоматически, когда мы закрываем чью-либо учётную запись через API (см. ссылку выше), и нам не удалось остановить это, используя документированный параметр block_ip: false.
Проблема с добавлением IP-адресов в список экранированных IP-адресов (Screened IPs) является отдельной от той, о которой я хочу сообщить здесь. Мы наблюдаем, что участники не заблокированы списком экранированных IP-адресов, но не могут войти в свою учетную запись через SSO, предположительно из-за сообщения «IP-адрес заблокирован».Есть ли еще какие-либо места, помимо списка экранированных IP-адресов, которые могут блокировать IP-адреса, на которые мне следует обратить внимание?
Похоже, вы вызываете функцию «удалить как спамера», которая автоматически добавляет IP-адрес и адрес электронной почты в чёрный список. Я думаю, вам стоит пересмотреть этот код. Вам нужно «простое удаление», как в интерфейсе, а не «удаление как спамера».
Это может быть правдой, но вопрос о том, как мы удаляем пользователей, обсуждается здесь.
Не уверен, является ли это отдельной проблемой, но я заметил, что в разделе «Заблокированные IP-адреса» столбец «Совпадения» показывает 0 совпадений для всех записей. Я проверил экспорт этой таблицы, и он подтверждает, что у всех IP-адресов 0 совпадений. Однако каждый день мы видим, как пользователи блокируются по IP-адресу при попытке входа (через SSO).
Однако, если посмотреть на раздел «Заблокированные электронные адреса», то у большинства из них есть совпадения! И там тоже есть столбец с IP-адресами… поэтому я подумал, что наконец-то нашёл причину, но ни один из блокируемых IP-адресов там тоже не указан.
Я также проверил раздел «Заблокированные электронные адреса», и ни IP-адрес, ни адрес электронной почты учётной записи, которая только что была заблокирована при входе, там не указаны.
Есть ли какие-то советы, куда ещё можно посмотреть?
Я думаю, что нашел проблему (в итоге она оказалась на нашей стороне), но есть несколько багов, о которых стоит сообщить. Хотя этот стек технологий мне не очень хорошо знаком, поэтому надеюсь, что кто-то сможет взглянуть внимательнее.
Во-первых, причина. При прямом просмотре таблицы базы данных 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 не вызывает эти совпадения?
Опять же, я должен сказать, что, скорее всего, вы вызываете через API функцию «Удалить как спамера». Если удаление спамеров с связанных IP-адресов происходит достаточно часто, запрет IP-адресов начинает автоматически расширяться. Я уверен, что именно это вы и наблюдаете.
И да, это так. Возможно, причина того, что ваш список отфильтрованных IP-адресов так велик, в том, что вы уже давно используете функцию «Удалить как спамера»? Вам этого не нужно.
Вам нужно выбрать «Только удалить», а не «Удалить и заблокировать», но почти всё, что вы опубликовали, указывает на то, что вы вызываете через API функцию «Удалить и заблокировать».
Проблема была не в используемой конечной точке, а в параметрах, так как API ожидает, что булевы значения будут переданы в виде строк ‘true’/‘false’, и я об этом не знал.
Выше упомянуто ещё несколько других ошибок, с которыми я столкнулся, но я не знаю, нужно ли их исправлять. В противном случае эту задачу можно закрыть. Спасибо.
