여기서 문제를 찾은 것 같습니다 (결국 문제는 우리 쪽에 있었지만), 보고할 버그가 몇 가지 있습니다. 다만 제가 익숙하지 않은 스택이라, 누군가가 더 자세히 살펴봐 주시면 좋겠습니다.
먼저 원인에 대해 말씀드리겠습니다. screened_ip_addresses 데이터베이스 테이블을 직접 확인해 보니, 차단되어서는 안 되는 두 개의 전체 블록(176.59.0.0/16과 109.252.0.0/16)이 차단되어 있었습니다. 이 항목들이 어떻게 추가되었는지 솔직히 모르겠고, 두 항목은 2월부터 존재하고 있었습니다. Discourse 관리자 화면에서 /16 블록 전체를 한 번에 차단할 수 있는 버튼이 있나요?!
어쨌든, 이것이 제 초기 문제의 주된 원인일 가능성이 높습니다. 이 문제를 해결하는 데 특히 어려웠던 점은 Discourse 팀이 살펴볼 필요가 있는 몇 가지 문제가 남아 있다는 것입니다:
-
차단된 이 범위는 어떤 이유인지 Screened IPs 목록에 표시되지 않습니다. 직접 데이터베이스를 확인해야만 찾을 수 있었습니다. 하지만 “176.59” 또는 "109.252"로 검색하면 항목들이 표시됩니다.
/admin/logs/screened_ip_addresses에서 결과 개수 제한이 적용되고 있는 건가요? -
내보내기(Export) 시에는 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를 통한 로그인이 이러한 매칭을 트리거하지 않는 건가요?