로그인 및 계정 생성에 SSO를 사용하고 있습니다. 포럼에서 로그인하거나 가입할 수 있는 다른 방법은 없습니다.
그러나 스크리닝된 IP 목록에는 매일 자동으로 추가되는 수십 개의 IP 주소가 포함되어 있습니다. 이는 정상적인가요? IP 주소가 스크리닝된 IP 목록에 추가되는 기준은 무엇인가요?
로그인 및 계정 생성에 SSO를 사용하고 있습니다. 포럼에서 로그인하거나 가입할 수 있는 다른 방법은 없습니다.
그러나 스크리닝된 IP 목록에는 매일 자동으로 추가되는 수십 개의 IP 주소가 포함되어 있습니다. 이는 정상적인가요? IP 주소가 스크리닝된 IP 목록에 추가되는 기준은 무엇인가요?
제가 생각할 수 있는 유일한 방법은 계정을 삭제할 때 “스패머 삭제” 버튼을 선택하는 것입니다.
좋은 지적입니다 — 계정을 API를 통해 삭제할 때 IP가 'Screened IPs’에 추가되고 있군요.
하지만 우리는 block_ip=false를 사용하여 DELETE 요청을 보내고 있습니다. 이는 Rails 로그에서 확인할 수 있습니다:
Parameters: {"delete_posts"=>"1", "block_email"=>"0", "blocked_urls"=>"0", "block_ip"=>"0", "id"=>"123"}
그런데도 IP가 차단되고 있으므로 어딘가에 버그가 있는 것 같습니다.
그럴 수도 있지만, 그렇게는 아닌 것 같습니다. 제가 찾은 유일한 사용자 삭제 엔드포인트를 사용하고 있습니다:
DELETE /admin/users/{id}.json
이 엔드포인트에는 기본값이 true인 block_ip 매개변수가 있으며, 저는 항상 이 값을 false로 설정하고 있습니다. 그럼에도 불구하고 IP가 차단된 IP(Screened IPs)에 추가되고 있습니다.
Reverse engineer the Discourse API 을 참고하여 사용자가 삭제될 때 정확히 어떤 요청이 전송되는지, 그리고 삭제만이라고 적힌 버튼을 눌렀을 때의 동작을 확인해 보시는 것이 좋습니다.
… 왜냐하면 삭제 후 IP가 스크리닝 목록에 추가되는 것을 보고 있다면, 사용자를 스팸으로 처리하여 삭제하고 있는 것, 즉 중간 버튼인 삭제 및 차단을 누르고 있다는 것을 확신할 수 있기 때문입니다.
이미 그렇게 해봤고, 삭제 API 엔드포인트는 제가 사용해 온 것으로, 두 동작(삭제만 수행 및 삭제 및 차단) 모두에 동일한 엔드포인트를 사용합니다. 유일한 차이점은 위에서 언급한 대로 사용되는 파라미터(block_ip, block_email, …)입니다.
드디어 제 요청에 문제가 있었던 원인을 파악했습니다: Discourse API는 truthy/falsy 값 대신 문자열 'true’와 'false’를 요구합니다. 문서에 있는 해당 주의 사항을 알아채지 못한 제 실수입니다.
아마도 이것이 이런 혼란을 초래했던 원인이었을 것입니다.
조급하게 말한 것 같네요. ![]()
Truthy/falsy 매개변수를 ‘true’/‘false’ 문자열로 수정했지만, 사용자를 삭제할 때 여전히 Screened IPs와 Screened Emails에 항목이 추가되고 있습니다.
API 호출에 대한 Rails 로그는 다음과 같습니다:
Started DELETE "/admin/users/9553.json" for 123.123.123.123 at 2021-06-10 00:01:21 +0000
Processing by Admin::UsersController#destroy as JSON
Parameters: {"delete_posts"=>"false", "block_email"=>"false", "blocked_urls"=>"false", "block_ip"=>"false", "id"=>"9553"}
Can't verify CSRF token authenticity.
Rendering text template
Rendered text template (Duration: 0.0ms | Allocations: 1)
Completed 418 in 8ms (Views: 1.4ms | ActiveRecord: 0.0ms | Allocations: 2301)
그리고 API를 호출하는 대신 웹 인터페이스를 통해 실행한 요청은 다음과 같습니다:
Started DELETE "/admin/users/49.json" for 123.123.123.123 at 2021-06-10 08:24:47 +0000
Processing by Admin::UsersController#destroy as JSON
Parameters: {"context"=>"/admin/users/49/XXX", "delete_posts"=>"true", "id"=>"49"}
Rendered text template (Duration: 0.0ms | Allocations: 1)
Completed 418 in 23ms (Views: 4.7ms | ActiveRecord: 0.0ms | Allocations: 1778)
즉, 몇 가지 테스트를 해본 결과, /admin/users/{id}.json API 엔드포인트의 매개변수는 실제로 ‘true’ 또는 'false’로 설정되었는지와 관계없이 존재하는 한 항상 true로 해석되는 것 같습니다.
'true’인 매개변수만 설정하고 'false’인 매개변수는 건너뛰기 시작하자, 더 이상 Screened IPs/emails에 항목이 추가되지 않았습니다.
이것이 의도된 동작인가요? 문서에서 이해한 내용과는 다릅니다.
Reverse engineer the Discourse API 토픽에서 관찰한 동작을 그대로 에뮬레이션했다면 문제없이 작동할 것입니다. ‘삭제만’ 버튼을 누를 때 네트워크 모니터에서 어떤 API 호출을 관찰하고 계신가요?
일부 경우, JS가 서버에 명시적으로 false를 전달하지 않으면 서버는 존재하는 모든 값을 true로 취급합니다. 여기서는 아마도 이러한 상황이 발생하고 있을 것입니다.