관리자로 만들기

[hellekin]

문제

1. 관리자가 실수로 포럼의 기밀 부분에 접근할 수 있습니다.
2. 이러한 원치 않는 접근이 기록되지 않습니다.
3. 관리자의 특권이 일반 사용자 경험을 가려주기 때문에, 관리자가 잘못된 설정을 놓칠 수 있습니다.

기능 설명

Impersonating a user 기능과 유사하게, 관리자 권한을 가진 사용자는 필요할 때만 관리자가 되어 관리 작업을 수행할 수 있어야 합니다.

사용자 위장(Impersonation) 기능과 달리, 이 기능은 일반 사용자 권한으로 복원하기 위해 로그아웃을 요구하지 않아야 합니다.

이 기능은 다음과 같은 역할을 합니다:

1. 관리자가 일반 사용자로 사이트를 탐색하여 다른 사용자의 일상적인 경험을 공유할 수 있게 합니다;
2. 관리자가 실수로 포럼의 비공개 공간에 접근하는 것을 방지합니다;
3. 관리자 접근에 대한 실제 로그를 통해 이러한 비공개 공간에 대한 무단 접근을 방지합니다.

첫 번째 항목은 유용합니다. 관리자 경험은 사용자 경험과 매우 다르기 때문에, 관리자가 사용자 문제(예: 카테고리나 그룹에 설정된 잘못된 권한 등)를 인식하지 못할 수 있기 때문입니다.

두 번째 항목은 기밀성이 요구되는 그룹의 경우 매우 중요할 수 있습니다. 링크를 클릭하면 관리자가 실수로 침입하여 기밀성을 깨뜨릴 수 있기 때문입니다.

세 번째 항목은 현재 전혀 책임지지 않고 있는 관리자로서, 포럼의 기밀 부분에 대한 무단 접근에 대해 책임을 질 수 있게 합니다.

어떻게 작동할 수 있을까?

• 권한 상승은 실제 관리자 계정에게만 사용 가능해야 합니다;
• "관리자"는 추가적인 신뢰 등급(예: 5등급 ^[1])으로 간주될 수 있습니다;
• “일반” 모드로 돌아가는 것은 단순히 이전 신뢰 등급(TL)으로 전환하는 것입니다;

전체적으로 새로운 "관리자 관점"을 제공하는 대신, 관리자 모드는 사용자 인터페이스의 추가적인 계층을 추가할 수 있습니다:

• _관리자이기 때문에_만 작동하는 링크를 강조 표시합니다
• _관리자이기 때문에_만 접근할 수 있는 카테고리를 강조 표시합니다
• 관리자이기 때문에 볼 수 있는 그룹 멤버십을 강조 표시합니다 (예: 그룹 멤버십에 대한 접근이 제한된 그룹의 멤버인 경우, 강조 표시가 적용되지 않음)
• 관리자만 볼 수 있는 정보를 강조 표시합니다

---

1. 크리스 마커의 영화 Level 5에 대한 참고. 이 영화에서는 컴퓨터 프로그래머가 고인이 된 남편의 오키나와 전투에 관한 비디오 게임을 완성하여 슬픔을 극복하려 합니다. ↩︎

[Moin]

이것은 다음과 유사하다고 생각합니다.

관리자와 모더레이터를 위한 "일반 모드" (예: "sudo" 같은 기능)

저는 Fedora 디스커스 사이트에서 관리자이자 참가자입니다. 이 두 역할을 분리할 수 있으면 좋겠습니다. 공식 게시물의 "스태프 색상"은 알고 있지만, 제가 말하는 것은 제 측면에서의 기능입니다. 로그인할 때마다 어디에나 관리자용 토크와 버튼이 표시되는 대신, 관리자 모드를 켜고 끌 수 있는 메뉴 토글이 있으면 좋겠습니다.

[hellekin]

비슷하다는 점은 이해하지만, 다른 토론에서 언급된 문제들이 이 문제와 관련이 있습니다:

@codinghorror

관리자로서 갖추어야 할 자질 중 하나는 자신이 지닌 책임과 반드시 존중해야 할 경계를 이해하는 것입니다. 이를 할 수 없다면 관리자 권한을 보유해서는 안 됩니다.

그런데, 관리자일 때 정상적으로 접근할 수 없는 기밀 대화에 대한 링크가 실제로는 접근 금지 상태임을 알 수 있는 방법이 없습니다. 이것은 어제 우리에게 떠올라 이 주제를 시작하게 만든 하나의 사례일 뿐이며, 관리자와 참가자의 역할이 분리되지 않을 때 문제가 될 수 있는 경우입니다.

더욱이, Discourse 팀이 모두 관리자가 되는 경향이 있다는 점을 볼 수 있는데, 이는 수평적 초권력을 만들어내고, 일반적인 사용과 특권 있는 사용을 구별하는 문화 형성에 도움이 되지 않습니다. 모든 커뮤니티가 수평적이지는 않으며, 때로는 관리자 권한을 가진 기술 담당자들이 포럼의 모든 것에 대해 신뢰할 수 없을 수 있습니다. 그리고 이는 경계 사례가 아닙니다: root가 모든 것을 보고 할 수 있다는 것은 시스템의 초기부터 컴퓨터 시스템에 내장되어 있는 것입니다. 권한은 분명 책임이 따르지만, 특히 괜찮은 것과 접근 금지 상태를 구별할 수 없을 때 선의만으로는 충분하지 않은 경우가 있습니다.

일반 계정과 관리자 계정을 처리하기 위한 “다른 브라우저 프로필 사용” 솔루션은 매우 실용적이지 않습니다, 특히 우리가 모두 손에 도구를 가질 수 있는 것에 익숙해지기 때문입니다. 관리자 기능이 필요할 때마다 새로운 브라우저를 실행하는 것은 매우 번거로울 수 있습니다(모든 사람이 자신의 머신에서 유휴 리소스를 차지하는 것을 좋아하거나 감당할 수 있는 것은 아닙니다). 또한, 특권화된 BOFH 상황이 발생하는 것을 방지하지도 못합니다.

@mattdm

의도된 태그 규칙을 우연히 위반하는 것을 원하지 않습니다. (비관리자 모더레이터도 우연히 이를 할 수 있을까요? 쉽게 테스트할 수도 없고요.)

별도의 관리자 계정을 만들고 내 주 계정을 일반 사용자로 강등할 수 있지만, 중요한 플래그 알림과 메시지를 놓칠까 두려워요.

@mattdm

글쎄요, 이건 마치 리눅스 시스템에서 항상 root로 실행하는 것과 비슷합니다. 단순히 경계를 존중하는 것뿐 아니라, 경계가 있는 것을 인식하지 못했을 때 우연히 그 경계를 넘지 않는 것도 중요합니다.

@codinghorror

우려를 이해하지만, 실제로는 큰 문제가 아닙니다.

시대는 변합니다. 여기서는 우연히 다른 사람들의 삶에 영향을 미친 기밀 정보에 접근한 관리자가 있었는데, 그들은 그렇게 해서는 안 되었습니다. 이는 프라이버시 침해입니다. 보안 문제입니다.

@leonardo

그 로직이 대부분 guardian.rb와 /lib/guardian/*.rb에 중앙 집중되어 있지만, 이러한 변경의 복잡성과 버그 발생 가능성은 매우 클 것이며, 이 기능의 필요성은 대체 수단에 비추어 볼 때 이를 훨씬 초과해야 하는데, 실제로는 그렇지 않습니다.

잠재적인 복잡성은 이해하지만, 핵심 문제는 여전히 남아 있으며 어떤 방식으로든 해결되어야 할 것입니다. 제 생각에는 코드 베이스가 성숙해졌으므로 이제 이 질문을 재검토하고, 제안된 접근 방식이 실행 가능한지 평가하는 것이 유용할 것입니다.

@Ivan_Rapekas

OP(첫 번째 게시자)는 대부분의 시간을 일반 사용자로 일하는 것을 의미했다고 가정합니다. 제 경우, 저도 단순한 사용자로서 느끼고 싶습니다:

• 버튼이 적음
• 모더레이션/관리자 작업에 대한 접근 불가
• 단순한 사용자 케이스 사용

업그레이드나 튜닝 후, 오해를 피하기 위해 일반 사용자가 보는 대로 포럼과 상호작용하고 싶습니다.

@Canapin

며칠 전 일어난 무언가를 떠올리게 합니다. 저는 포럼을 이전하는 과정에 있습니다.

맞습니다! 이러한 종류의 (경계 침범) 문제에 대한 경고와 보호 장치가 유용할 것입니다.

---

기존 플러그인에 대해:

• GitHub - discourse/discourse-anonymous-moderators · GitHub 가 유용할 수 있지만, 이메일 처리를 위한 최근 변경(Enabling e-mail normalization by default)이 이를 변경할 수 있습니다 – 기본 설정이 없음을 신뢰하는 것은 문제가 될 수 있습니다.
• GitHub - discourse/discourse-staff-alias: Allow staff users to post under an alias · GitHub 는 _게시물 작성_에만 제한됩니다.

위에서 언급한 모든 이유를 들어, 고전적이고 잘 알려진 sudo 은유를 사용하여 참가자와 관리자 사이를 정말로 깨끗하게 분리하는 것을 선호합니다.

[Ed_S]

sudo 메커니즘(Windows에서는 사용자 계정 제어 대화상함)이 계정이 관리자 권한을 가질 잠재력은 있으면서도 항상 그런 권한을 행사하지는 않는 좋은 방법이라는 데 동의합니다.

제가 운영하는 포럼 중 하나에서는 관리자 로그인을 사용하되, 평소에는 항상 일반 계정으로 로그인하기 위해 ‘사용자 위장(Impersonate User)’ 기능을 사용합니다. 관리자 권한이 필요할 때는 로그아웃을 한 뒤 다시 로그인합니다. 이렇게 하면 두 개의 계정이 필요하게 됩니다.

두 계정을 사용하는 이점 중 하나는, 일반 계정으로 게시글을 작성하거나 댓글을 달 때 중요한 인물이나 권위 있는 사람으로 보이지 않는다는 점입니다. (때때로 관리자로 댓글을 달면 공식 선언이나 경찰 조치로 받아들여질 수 있습니다. 이는 독자의 문화와 기대에 따라 다릅니다.)

[hellekin]

이 기능이 최종적으로 구현된다면(표결에 참여하는 것을 잊지 마세요!), 구현되기까지 시간이 걸릴 것이므로, 우리는 두 개의 계정을 사용하는 방안을 검토하고 있습니다. 즉, 기존 계정을 일반 계정으로 전환하는 것을 의미합니다. 이 작업에 포함된 내용은 다음과 같습니다(이 게시글을 편집하거나 위키로 만들어 주의사항을 포함하여 최신 문서를 유지하도록 하겠습니다)…

아직 미검증: 이것은 모두 제 머리에서 나온 이론적인 내용입니다.

기존 Discourse 관리자 계정을 일반 사용자 계정으로 전환하기

원본 계정의 히스토리와 "포럼 경험"을 잃고 싶지 않으므로, 관리자 권한을 제거하기 전에 신중하게 진행해야 합니다.

조건: 이메일이 _original-me@email.example_인 사용자 _me_가 있다고 가정합니다.

첫 번째 경우: DISCOURSE_DEVELOPER_EMAILS에 포함된 관리자 계정

관리자 계정의 이메일이 DISCOURSE_DEVELOPER_EMAILS의 일부라면, 해당 계정을 일반 계정으로 강등할 수 없습니다.

1. 관리자가 될 새 계정을 생성합니다. 예: 이메일이 _original-me+admin@email.example_인 me2.
2. me 계정으로 부터 새 계정 me2에게 관리자 권한을 부여합니다.
3. app.yml (이중 컨테이너 설정을 사용하는 경우 web_only.yml)을 편집하여 original-me@email.example을 original-me+admin@email.example로 교체하고 컨테이너를 재구축합니다.
4. me2 계정으로 원본 me 계정을 강등합니다.

이제 모든 경험을 가진 일반 사용자 계정(me)과 관리자 전용 계정(me2)을 갖추게 되었습니다: "사후 처리"로 이동하세요.

두 번째 경우: 일반 사용자에서 승격된 관리자 계정

컨테이너를 재구축하지 않고도 이 사용자를 강등할 수 있으므로 더 간단합니다.

1. 관리자가 될 새 계정을 생성합니다. 예: 이메일이 _original-me+admin@email.example_인 me2.
2. me 계정으로 부터 새 계정 me2에게 관리자 권한을 부여합니다.
3. me2 계정으로 원본 me 계정을 강등합니다.

이제 모든 경험을 가진 일반 사용자 계정(me)과 관리자 전용 계정(me2)을 갖추게 되었습니다: "사후 처리"로 이동하세요.

사후 처리 (Aftermath)

이전에는 관리자 권한이 있는 단일 사용자 계정이 있었습니다: 시스템 업그레이드, 검토 플래그 알림을 받았으며, 본인이 보아서는 안 되는 영역(예: 암호화되지 않은 경우의 개인 사용자 메시지)이나 소속되지 않은 그룹으로 제한된 카테고리에도 접근할 수 있었습니다. 이제 이 모든 것이 사라졌습니다! 이제 이전에 단일 사용자/관리자 계정으로 하던 일을 하려면 정기적으로 관리자 계정에 접속해야 합니다(이것이 제안된 기능이 유용한 또 다른 이유이기도 합니다). 실시간 관리자 알림을 원한다면(예: Firefox의 개인 탭 또는 다른 웹 브라우저의 동등한 기능 사용) 두 계정을 동시에 여는 습관을 들여야 합니다.

주의사항

관리자 계정은 관리 외의 _어떤 용도_로도 사용해서는 안 됩니다.

관리자 권한으로 토론을 둘러보지 마세요! 이 시간은 본인의 신뢰 수준(trust level) 상승에 소모되며, 개인으로서 접근이 금지된 링크를 클릭할 수 있는지 알 수 없습니다.

관리자 계정으로 접속 중 무언가를 읽고 반응하게 된다면, 일반 사용자 탭으로 전환하여 원래 URL로 이동하거나, 일반 사용자에게 해당 섹션에 대한 접근 권한이 없다면: 즉시 잊어버리세요(물론, 관리자 모자로 반응해야 하는 경우를 제외하고).

관리자 계정을 다르게 보이도록 설정해야 합니다

관리자 계정과 일반 사용자 계정을 절대로 혼동하지 않도록 아바타를 변경하세요. 프로필을 비공개로 설정하세요. 배경 이미지나 테마, 이름을 "ADMIN"을 포함하거나 “이 계정은 게시물을 작성하지 않습니다” 등으로 변경하세요. 관리자 계정으로 게시물을 작성하고 싶은 유혹을 받지 않도록 하세요.

관리자 계정의 알림을 필터링하도록 설정해야 합니다

TODO: 이 섹션 상세화

관리자 계정은 이메일 알림을 모두 음소거하도록 설정해야 합니다(예: 항상 관리자 탭을 열어둘 필요가 없도록 하기 위해 이러한 알림을 받기를 원한다면 제외). 그리고 개인으로서 받는 알림과 관리자 역할로 받는 알림을 명확히 구별할 수 있어야 합니다.

데스크톱 알림을 설정하여 플래그와 중요한 메시지를 놓치지 않는 것이 좋습니다.

스태프 카테고리와 속삭임(whispers)은 어떻게 할까요?

네, 관리자와 일반 사용자 참여를 위해 두 개의 별도 계정을 사용하면 또 다른 복잡한 문제에 직면하게 됩니다. 때로는 포럼에서 관리자로 상호작용해야 합니다. 이것은 아마도 피할 수 없을 것입니다. 정신분열증에 걸리지 않도록 하고, 스태프 개입을 가능한 한 최소화하세요. 이 고된 문제를 해결하는 전략을 보고해 주시고, 이 기능을 구현하도록 모든 관리자 Discourse 팀을 독려해 주세요.

두 계정 솔루션의 장점

1. 참여와 관리 간의 명확한 분리 (어떤 의미에서든)
2. 일반 계정에서 실수를 할 수 없습니다
3. 모든 관리자 작업이 적절하게 기록됩니다
4. 사용자로 포럼을 경험할 때 다른 사용자들과 동일한 경험을 하므로 권한 문제를 쉽게 발견할 수 있습니다
5. admin으로 게시물을 작성했지만 본인으로 작성할 의도였다면, 소유권을 다른 계정으로 변경할 수 있습니다(하지만 이는 두 계정을 가지는 취지를 어느 정도 무너뜨립니다).

[NateDhaliwal]

즉, 관리자는 일반 사용자 또는 TL4이지만, 특수한 관리자 기능을 사용하려면 '관리자 모드’를 켜야 한다는 거죠?
그렇다면, 관리자가 이 모드를 항상 켜두는 걸 막는 것은 무엇인가요?

[Ed_S]

@hellekin

실시간 관리자 알림을 원하신다면, 두 계정을 동시에 열기 위해 이 규율을 구축해야 합니다.

흥미로운 지적이네요. 콘텐츠 없이 알림 전달을 그룹이 제어할 수 있는 방법이 있을까요? “플래그가 지정된 게시물이 있습니다”, “대기 중인 메시지가 있습니다”, "설치된 버전이 최신이 아닙니다"와 같은 형태로요.

[Ed_S]

@NateDhaliwal

관리자들이 항상 켜두는 걸 막는 게 뭐가 있나요?

이런 아이디어가 있습니다: 관리자 역할은 공개 카테고리나 스레드에 게시물을 올릴 수 없고, 게시물에 좋아요를 누를 수도 없습니다.

[Ar_D (Arpit D)]

또한, 일반 사용자처럼 계정을 무시할 수도 있음을 의미합니다. 무시하길 원할 경우, 관리자로부터 필요한 업데이트만 받으면 됩니다.
정말 멋진 기능입니다