저는 Fedora 디스커스 사이트에서 관리자이자 참가자입니다. 이 두 역할을 분리할 수 있으면 좋겠습니다. 공식 게시물의 "스태프 색상"은 알고 있지만, 제가 말하는 것은 제 측면에서의 기능입니다. 로그인할 때마다 어디에나 관리자용 토크와 버튼이 표시되는 대신, 관리자 모드를 켜고 끌 수 있는 메뉴 토글이 있으면 좋겠습니다.
19개의 좋아요
7개의 좋아요
또한 다음도 있습니다.
이 두 플러그인 모두 스태프가 자신의 신원을 숨길 수 있게 해줍니다. 즉, 더 ‘공식적인’ 것처럼 보이는 계정으로 게시물을 작성할 수 있으며, 이는 개인으로 명확하게 추적될 수 없습니다.
하지만 이것이 질문하신 내용과는 조금 다를 수 있습니다. 일반 사용자에게 보이는 것처럼 Discourse를 보이게/느껴지게 하되, "sudo 모드"에 진입하여 관리자 전용 추가 기능을 사용할 수 있게 하는 방법을 원하시는 것 같습니다.
구현하기가 꽤 어려울 것 같습니다… 하지만 꽤 멋진 아이디어입니다! 몇 년 전(팀에 합류하기 전에) 저는 자체 호스팅하는 포럼을 위해 이 컴포넌트를 만들었습니다. 동일한 아이디어(일반/관리자 권한을 명확히 표시)를 가지고 있지만, 매우 구체적인 하나의 경우로 제한됩니다:
사이트에서 자주 혼란을 일으키는 다른 제한적인 경우가 있다면, 관리자 전용 작업을 수행하기 전에 경고 팝업을 표시하는 유사한 테마 컴포넌트를 만드는 것이 가능할 수 있습니다.
8개의 좋아요
네, 정확합니다. 아마도 시스템 관리자(sysadmin)로 일한 수년의 경험에서 비롯된 것 같습니다. 실무 경험을 통해 "최소 권한 원칙"이 몸에 배었거든요. (프로덕션 시스템에서 잘못된 위치에 루트 권한으로 rm -rf를 실행하는 건 일종의 관문과도 같은 경험입니다!)
7개의 좋아요
이것도 제게 흥미로운 주제입니다. 현재 제가 사용하는 임시 해결책은 크롬과 엣지를 함께 사용하는 것입니다. 크롬에는 일반 관리자 계정을, 엣지에는 관리자 계정으로 로그인한 상태에서 이메일이 만료된 사용자 계정을 *모사(impersonate)*하고 있습니다. 모사를 사용하는 이유는 IT 부서에 문의하기 싫기 때문이에요.
여러분의 상황에서는 두 번째 로그인을 생성하고, 하나는 관리자용 브라우저로, 다른 하나는 사용자용 브라우저로 사용하면 될 것 같습니다. 완벽하지는 않지만, 제 경우에는 충분히 잘 작동하고 있습니다.
6개의 좋아요
이 기능이 유용하게 쓰일 수 있는 좋은 예시를 하나 소개합니다:
의도된 태그 규칙을 실수로 위반하는 일이 일어나지 않도록 막고 싶습니다. (관리자가 아닌 모더레이터도 실수로 이런 일이 생길 수 있을까요? 쉽게 테스트해 볼 수도 없는 상황입니다.)
별도의 관리자 계정을 만들고 기존 주 계정을 일반 사용자로 강등할 수는 있지만, 중요한 플래그 알림이나 메시지를 놓치게 될까 봐 걱정됩니다.
4개의 좋아요
이것은 브라우저 자체에서 처리되는 부분입니다.
6개의 좋아요
그게 그냥 브라우저 프로필 전체를 교체할 수 있게 해주는 것 같은데, 도움이 될 것 같지 않아요. 관리자용으로 완전히 다른 Discourse 사용자 계정을 만들지 않는 한은요.
아니면 제가 무언가를 놓치고 있는 건가요. 예를 들어, @codinghorror 님의 계정은 여기에 관리자로 표시되어 있으니까, 제가 완전히 오해하고 있는 게 아니라면 지금 관리자 모드로 실행 중이시겠죠. 그런데 동시에 사이트 사용자로서도 활동하고 계신데요. 설정된 태그 규칙을 지키지 않는 게시물을 실수로 작성하게 되는 경우가 생기진 않나요? (저는 그런 실수를 한 번 이상 했었거든요…)
3개의 좋아요
정말 그렇지 않아요. 관리자가 되는 것의 일부는 자신이 가진 책임과 반드시 지켜야 할 경계를 이해하는 것입니다. 그걸 할 수 없다면 관리자 권한을 가질 자격이 없어요.
하지만 초안전 모드를 원하시는 분들도 충분히 이해하며, 절대 확실하게 해야 할 때는 일반 사용자로 로그인하는 두 개의 계정을 사용하는 것을 추천합니다. 내장된 브라우저 프로필 지원 기능을 이용하면 이걸 매우 쉽게 할 수 있어요.
8개의 좋아요
음, 이건 사실 리눅스 시스템에서 항상 루트 권한으로 실행하는 것과 비슷해요. 단순히 경계를 존중하는 것뿐만 아니라, 경계가 있는지도 모르고 우연히 넘지 않는 것도 중요하거든요. 설정으로 들어가는 것처럼 일부 동작은 우연히 일어나지 않지만, 관리자 권한이 설정을 우회하는 작은 부분들이 꽤 있고, 그걸 우회하고 있다는 표시도 전혀 없는 것 같아요.
위에 말했듯이, 두 번째 계정을 두는 건 별로 좋지 않아요. 왜냐하면 그 계정의 알림을 자주 확인하지 못하거든요.
7개의 좋아요
그 우려는 이해하지만, 실제로는 큰 문제가 되지 않습니다. 적어도 이 프로젝트를 10년째 진행해 온 제 경험상으로는 그렇습니다.
(또한, 오랫동안 부재 중인 스태프의 접근 권한은 자동으로 취소되고, 이메일 재확인을 요구하기 때문에, 제 생각에는 이 부분의 대부분이 자동으로 해결됩니다.)
1개의 좋아요
맷님, 안녕하세요!
추가로 몇 가지 말씀드리고 싶은 부분이 있습니다. 관리자 사용자가 일반 사용자처럼 행동할 수 있는 가능성을 허용한다면, 관리자 관련 권한 부여 로직 전체에 추가적인 복잡성을 더하게 됩니다.
해당 로직은 대부분 guardian.rb와 /lib/guardian/*.rb에 중앙 집중되어 있지만, 이러한 변경으로 인한 복잡성과 버그 발생 가능성은 매우 클 것입니다. 그리고 이러한 기능의 필요성은 그 위험성을 상쇄할 만큼 충분히 크지 않습니다. 왜냐하면 다른 대안들이 존재하기 때문입니다.
1개의 좋아요
일부 우연히 발생할 수 있는 문제에 대해 좀 더 구체적인 “보호” 기능을 고려해 주실 수 있을까요? 예를 들어, "스태프는 카테고리 태그 규칙을 준수해야 합니다"와 같은 설정을 말하는 거예요. 솔직히 이 기능 하나만으로도 제가 겪고 있는 실제 문제의 대부분을 해결할 수 있을 것 같아요.
아니면… 글자 수 제한 같은 다른 기능은 관리자조차도 보호되는 반면, 이 특정 기능만 그런 게 아닌 것 같아서 좀 이상하게 느껴집니다. 옵션을 추가하는 대신, 이 기능을 _기본 동작 방식_으로 만드는 것이 더 나은 해결책이 아닐까요?
게시물 길이를 추가하려면 전체 데이터베이스를 변경해야 합니다. 각 필드별로 데이터베이스에 저장할 수 있는 최대 문자 수가 정해져 있기 때문입니다.
내 생각에는 이게 논리적 비약(non sequitur)인 것 같은데, 혹시 내가 무언가를 놓치고 있는 건지 모르겠어요. 즉:
- 관리자인 상태에서
min post length(최소 글자 수)보다 짧은 글을 게시하려고 하면, 일반적인 오류 메시지가 표시되고 진행할 수 없습니다. - 관리자인 상태에서 태그가 필수인 카테고리에 태그 없이 글을 게시하려고 하면, 그냥 진행이 가능합니다.
여기서 데이터베이스에는 무엇이 저장되는 건가요?
4개의 좋아요
아, 죄송합니다. 저는 게시물/제목 길이만을 의미했습니다. 실제 데이터베이스에 저장되는 필드에는 게시물 내용의 최대 길이가 제한되어 있습니다. 게시물 제목에도 유사한 규칙이 적용되어, 해당 데이터베이스 필드에 할당된 최대 문자 수가 있습니다.
따라서 관리자가 "900,000자 길이의 게시물을 작성하고 싶다"거나 "500자 길이의 제목을 가진 게시물을 작성하고 싶다"고 결정하더라도, 데이터베이스를 변경하지 않는 한 불가능합니다.
실제로는 기술적인 세부 사항이지만, 게시물의 길이에 대해 언급하셨기 때문에 이런 부분을 떠올리게 되었습니다.
1개의 좋아요
아, 알겠습니다. 네, 제 걱정과 정반대네요 
OP가 대부분의 시간 동안 일반 사용자로 활동하는 것을 의미했다고 생각합니다. 저 역시 단순한 사용자로 느끼고 싶습니다:
- 버튼이 적어야 합니다
- 모더레이터/관리자 작업에 접근할 수 없어야 합니다
- 단순한 사용자 시나리오를 사용해야 합니다
업그레이드나 튜닝 후에는 오해를 피하기 위해 일반 사용자가 보는 것과 동일한 방식으로 포럼과 상호작용하고 싶습니다.
제 커뮤니티의 경우, 관리자 모드는 업그레이드나 플러그인 및 UI 테스트 시에만 필요합니다. 항상 모더레이터일 필요도 없습니다. 또한 저 같은 일부 사람들에게는 두 개의 계정을 갖는 것보다 일시적으로 관리자로 전환하는 것이 더 나은 것 같습니다.
OP는 sudo에 대해 언급했습니다. 이는 거의 동일하지만 반대의 개념입니다. 저는 보통 특정 사례를 확인하기 위해 일시적으로 익명 모드로 전환합니다. 어쨌든, 특수한 일반 계정에서 'impersonate’와 같은 가벼운 옵션으로 관리자 모드를 활성화할 수 있다면 좋겠습니다.
7개의 좋아요
며칠 전 일어난 일을 떠올리게 합니다. 저는 현재 포럼을 이전하는 중입니다.
저는 기존 포럼의 관리자에게 관리자 권한을 부여했습니다.
그는 다른 두 포럼의 Discourse 사용자이며, 동시에 모더레이터이기도 합니다. 그래서 그는 Discourse 인터페이스와 내비게이션에 대해 어느 정도 알고 있습니다.
그의 관리자 계정에서(저는 그에게 가이드라인을 제공하지 않고 스스로 발견하도록 맡겼습니다) 그는 다른 사람들의 직접 메시지를 볼 수 있다는 사실에 놀랐다고 말했습니다. 그는 공개 프로필 페이지에서 무작위로 여기저기 클릭하다가 직접 메시지 목록을 보게 되었고, 이에 대해 놀라움을 표했습니다.
그는 갑자기 "아, 내가 있어야 할 자리가 아닌 것 같은데"라고 말했습니다. (이것은 현재 관리/모더레이션 목적이 없다면 이 자리에 있어서는 안 된다는 의미로 이해됩니다.)
그는 자신의 프로필에서 자신의 직접 메시지에 접근하듯, 인터페이스를 통해 이 메시지에 쉽게 접근할 수 있다는 사실에 대해 전혀 알지 못했습니다.
또한, 2018년부터 두 개의 Discourse 포럼 관리자로 활동해 온 저에게도 몇 주 전에 같은 일이 발생했습니다… 
제 의견으로는, 사용자의 공개 프로필에서 “직접 메시지” 탭을 관리자로서 클릭할 때, 그것이 모더레이션 또는 관리 행위임을, 그리고 "비공개"로 의도된 것들을 보게 될 것임을(사용자의 99%가 그렇게 생각할 것입니다) 알려주는 아이콘이나 어떤 형태의 경고가 있어야 한다고 생각합니다. 
6개의 좋아요
그래서… 이 문제에 대해 생각해보니, 결국 큰 변경 사항이 아니라는 생각이 들었습니다. 물론 여기저기 흩어진 로직이 많긴 하지만, 결국 is_admin 또는 is_staff를 확인하는 것으로 귀결되지 않나요?
"sudo"는 단순히 “staff_mode” 토글만 추가하면 되고, is_staff와 is_admin 함수는 해당 토글의 상태와 user.admin 또는 user.staff 플래그를 AND로 확인하면 됩니다. (물론 토글을 활성화하는 데에는 user.admin 또는 user.staff 값만 단순히 확인하는 특별한 체크가 필요합니다.)
1개의 좋아요