내 포럼이 공격을 받아 원치 않는 게시물이 스팸으로 도배되었습니다. 직원들이 정리할 수 있도록 포럼을 비활성화하는 방법은 무엇인가요?
포럼을 “끄는” 것만으로 마법처럼 모든 사용자가 계속 사용할 수 있게 되지는 않습니다.
스팸을 삭제할 때까지 모든 주제를 일괄 비공개로 설정하고, 그 후 남은 주제들을 다시 공개하는 방법을 고려해 볼 수 있습니다:
관리자만 게시할 수 있도록 포럼을 읽기 전용으로 설정할 수 있습니다. Discourse의 읽기 전용 모드
@pfaffman 그건 “visible” 부분을 해결하지는 못하네요 
카테고리 권한을 모두 스태프 전용으로 변경하는 것이 가장 간단할 것 같습니다. 물론 어딘가에 설명을 덧붙여 두는 것이 좋겠죠.
기존 권한을 먼저 기록하기 위해 데이터 탐색기 쿼리를 실행해 볼 수 있고, 포럼이 크거나 복잡한 경우라면 Rails 콘솔에서 일괄 작업을 수행하는 것도 고려해 볼 수 있습니다.
이렇게 하면 필요한 결과를 얻을 수 있을 것입니다. 또한 카테고리별로 정리가 완료될 때마다 콘텐츠를 순차적으로 공개할 수도 있습니다.
최근에도 비슷한 문제를 고민해 보았는데요.
단계가 다음과 같을까요?
직원 전용 쓰기 모드 활성화 Read Only Modes in Discourse- 관리자 설정에서
로그인 필수활성화 - Logout all users through the rails console
로컬 로그인 활성화비활성화 (그리고 모든 SSO)/u/admin을 사용하여 관리자 계정으로 로그인
아. 그 부분을 놓쳤네요.
그 경우, DNS를 변경해서 더 이상 포럼을 가리키지 않게 하고, 관리자들로 하여금 /etc/hosts(또는 동등한 설정)를 올바른 IP 주소로 가리키도록 구성해야 합니다. 하지만 그것은 정말로 Discourse의 문제가 아니라, 시스템 관리자의 해킹(hack)입니다.
고맙습니다. 범주가 적어서 수동으로 처리할 수 있었습니다(좀 번거롭긴 했지만).
이들은 단순히 다시 로그인할 수 있으므로 이 방법이 작동하지 않을 것 같습니다:
그 부분 이후로 다시 한번 생각해 보게 되었습니다. 로컬 로그인을 비활성화하는 것이 적절한 대안 또는 추가 단계가 될 수 있을까요? (그리고/또는 SSO)
물론 OAuth 방법도 꺼야 하지만, 네, 그렇게 하면 잘 작동할 수 있어. 다만 실수로 스스로 로그아웃되지 않도록 조심해 (예: 사이트를 복구하는 경우).
그 경우라면 콘솔에서 로그인 기능을 다시 켜면 되니까. 메타를 위해 이걸 계획하고 있는 거야? 
하, 아니요, 그런 건 아니에요. 그냥 궁금해서요. 
비상시에 대비해 유용한 계획인 것 같아요. 다만 단계가 너무 많다면 다른 방법이 더 편할 수도 있겠네요.
위에서 언급한 추가 단계를 편집해서 반영할게요. 
생각해보니, 모든 사용자를 로그아웃시킨 다음 로그인을 비활성화하는 건 스태프에게 쓸모없는 작업만 남게 만들 수 있는 거 아닌가요?
