가끔 누군가를 impersonate(대리 접속)할 때(그다지 자주 하는 일은 아니지만) 깜빡하고 관리자 권한으로 할 수 있는 일들을 계속 시도하다가, 결국 다른 사람의 계정에 로그인되어 있다는 사실을 깨닫곤 합니다.
현재 방식의 또 다른 단점은 사용자 아바타를 클릭해야 한다는 점입니다. 5개의 새로운 알림이 있는 사용자를 impersonate하고 있었는데, 그의 계정을 로그아웃하기 위해 프로필을 클릭하니 그 알림들이 읽음 처리가 되어 더 이상 새 알림이 있다는 (5) 배지가 표시되지 않았습니다. 그가 돌아왔을 때 얼마나 속상할지 모르겠네요! 그래도 이메일 알림을 받아 다시 돌아올 수 있기를 바랍니다!
제가 구축하고 현재 관리 중인 다른 커뮤니티는 Higher Logic 플랫폼을 사용합니다. Higher Logic보다 Discourse를 사용하는 것이 얼마나 더 좋은지 말로 다 표현할 수 없습니다. 하지만 이 이야기를 꺼낸 이상, 그들의 사용자 impersonate 방식은 꽤 마음에 듭니다…
오늘 이 기능이 꼭 필요하게 되었습니다. 저는 @system 계정으로 카테고리 가이드라인이나 다른 고정된 주제나 그 안의 답변을 게시할 때 impersonate 기능을 사용합니다. 현재는 제 계정으로 게시한 뒤 소유권을 @system으로 변경하는 방식으로 처리하고 있지만, 누군가 해당 주제를 감시(watching) 상태로 설정해 두었다면 그것이 저였다는 것을 알게 될 것입니다. 이러한 게시물을 올릴 때 반드시 익명성을 유지하려는 것은 아니지만, 적어도 제 이름으로 표시되지는 않기를 바랍니다. 이런 용도로만 사용할 대체 계정을 만들 수도 있지만, 그럴 때마다 프라이빗 창에서 로그인해야 하므로 사용자 경험(UX) 측면에서 좋지 않습니다.
@sam 동의합니다. 태그를 붙인 것은 죄송합니다. 하지만 저는 수년 동안 이 문제를 아무 때나 언급해 왔고, 일부 사용자에게는 매우 중요한 사안입니다. ‘인용(Impersonate)’ 기능은 특히 Discourse를 내부(업무) 소통 및 협업 플랫폼으로 사용할 때 사용자 프라이버시를 심각한 우려로 만드는 유일한 기능입니다.
과거에 이 기능을 사용했고, 현재는 우리 노동조합을 위해 Discourse 인스턴스를 다시 구축하고 있습니다. 단, 조합원 전체를 위한 것이 아니라 선출된 임원진 전용입니다. 이전 인스턴스를 관리하던 시절 저는 대부분의 일반 조합원처럼 평범한 대표였습니다. 지금은 단체의 리더십/관리 직위에 있으므로, 제 조직 내 역할이 모든 카테고리의 모든 자료를 볼 수 있는 Discourse 관리자의 권한과 충돌하지는 않습니다. 하지만 당시에는 상황이 달랐습니다…
우리 집행부는 관리자가 (집행부) 권한이 있는 카테고리 내에서의 토론을 볼 수 있는 능력을 가지고 있는 것에 대해 심각한 우려를 표했습니다. 저는 CSS를 사용하여(관리자에게도 숨김) 비집행부 구성원에게 해당 카테고리를 숨기는 해킹적인 방식으로 해결했고, 특정 테마 구성 요소인 "user privacy"를 제가 비활성화했는지 확인할 수 있도록 로그를 확인하는 방법을 안내했습니다.
또 다른 주요 우려 사항은, 계약된 IT 담당자가 아닌 Discourse 관리자(다시 강조합니다)인 활동적인 대표가 다른 사용자를 사칭하여 개인 메시지를 읽고, 누군가의 개인 설정과 자재(messy text: goods)를 만질 수 있다는 점이었습니다.
제가 할 수 있는 말은, 관리자가 전역적인 보기 권한을 갖지 않고, 대신 사이트 관리 권한에 초점을 맞추며 기본적으로 자신이 할당된 콘텐츠만 볼 수 있도록 하는 방식이 있다면 좋겠다는 것입니다. 또한, 관리 스태프가 이러한 작업을 수행할 때 모든 사용자에게 명확하게 알리는 알림 시스템이 있다면 좋겠습니다.
이를 'Discourse Teams’와 유사한 이름으로, 예를 들어 'Discourse Professional’이라 부를 수 있습니다. 인터넷 포럼보다는 비즈니스 지식, 협업 및 소통 플랫폼에 더 초점을 맞춘 것입니다. 관리자가 모든 것을 볼 수 있는 능력이 제한되거나 축소 또는 제거된다면, Discourse는 이 역할에서 빛을 발할 것입니다. (가장 중심적인 문제는 프로필/메시지 탭을 통한 사칭과 메시지 읽기입니다.)
대신, 임의 사용자(impersonation)에 일부 마찰(friction)을 추가하는 다른 접근 방식이 있을 수 있습니다.
“정말 확인” 팝업을 추가하여, 이 동작이 기록된다는 점을 상기시키고, 단순히 무언가를 테스트하려는 경우 테스트용 사용자를 생성한 후 완료 시 삭제하는 것이 더 적합할 수 있음을 안내합니다. 일종의 적시에 교육(just in time education)이라 할 수 있습니다.
백업 다운로드와 유사하게, 임의 사용자 링크를 이메일로 전송합니다(이 경우 별도의 창에서 로그인할 수 있는 추가적인 이점이 있을 수 있음)
임의 사용자 기능을 비활성화할 수 있는 관리자 설정도 좋은 아이디어라고 생각합니다. 기본값은 비활성화 상태로 두면 됩니다. 숨겨진 설정일 필요는 없지만, 백업 복원과 마찬가지로 이러한 설정이 존재하면 누군가가 다른 사용자를 임의로 사용하는 습관이 들거나 실수로 그렇게 하는 위험을 줄일 수 있습니다.
사용자가 기이한 문제를 겪는데, 관리자나 해당 사용자의 가상 계정이 이를 찾지 못하거나, 다른 사용자 중 극소수만 보고하는 경우입니다.
프라이버시는 상대적인 문제입니다. 대부분의 포럼에서는 사용자의 개인 정보가 전혀 존재하지 않는 상황이라고 주장합니다. 따라서 역할 대체는 최소한 하나의 옵션으로 제공되어야 합니다. 해당 상황이 발생했을 때 자동으로 알림을 보내는 것은 나쁜 아이디어가 아니며, 실제로는 꽤 자주 불필요할 수 있지만, 더 개방적인 해결책입니다.
이 기능이 안정화되면 impersonation_enabled_groups를 활용하여 반대로도 적용할 수 있습니다. 즉, 일반 멤버로 참여하다가 필요할 때만 관리자 권한으로 전환하는 방식이죠… 흔히 말하는 sudo 모드 같은 겁니다. 이렇게 하면 필요에 따라 페르소나를 바꿀 수 있는 방법도 생길 수 있습니다. 예를 들어, Discourse Staff Alias 에서는 가짜 위장(impersonation)을 단일 팀 별칭으로 제한하고 있지만, 위장 기능을 확장하면 다양한 기준에 따라 페르소나를 변경할 수 있게 될 것입니다…
예를 들어, @well-being.team 멤버는 개인적인 불만을 피하기 위해 그룹 별칭으로 게시물을 작성할 수 있고, 저자는 인터랙티브 스토리를 쓰기 위해 @narrator나 @characterN으로 글을 쓸 수 있으며, 선생님은 학생의 관점을 이해하기 위해 학생으로 위장할 수 있습니다… 모두 사용자 정의 가능한 그룹에 따라 적용됩니다.
제가 생각하기에 중요한 기능 중 하나는 위장 세션이 적절히 기록되고, 위장된 사용자가 그 사실을 알 수 있어야 한다는 점입니다.
사용자 관리 페이지에서 @user_to_impersonate로 전환처럼, 그리고 대리 실행을 중지하는 버튼에는 @user_who_impersonated로 전환처럼 더 직관적인 용어로 변경하는 것이 어떨까 합니다 (여기서 '전환’이라는 표현은 의도된 비유입니다). 이렇게 하면 번역이 훨씬 쉬워질 뿐만 아니라, 영어를 모국어로 하지 않는 사용자들에게도 이해하기가 더 쉬워질 것입니다.
오늘 테스트 중 다른 문제점들도 몇 가지 발견했습니다:
삭제나 병합 기능과 유사하게, 대리 실행을 시작할 때 확인 모달(Modal)이 표시되어야 한다고 생각합니다. 이는 버튼을 실수로 누를 경우 되돌아갈 수 있게 해 줄 뿐만 아니라, 관리자로서 사용자가 곧 수행할 작업이 무엇인지, 해당 작업이 기록될 것인지를 알 수 있으며, 다시 로그인하지 않고도 원래 계정으로 전환할 수 있다는 점을 교육하는 데 도움이 됩니다.
대리 실행 상태와 원래 계정으로의 전환은 스태프 액션 로그에 기록되지만, 대리 실행 중에 수행된 실제 작업들은 기록되지 않습니다. 이 기능이 오용될 가능성이 높다는 점을 고려하면(실수든 의도적이든), 이 부분도 기록하는 것이 합리적이라고 생각합니다.
오래된 문제이지만, 사용자가 대리 실행되면 사용자 목록과 사용자 관리 화면에서 해당 사용자의 '마지막 접속일’이 갱신되는 문제가 여전히 남아 있습니다. (설치되어 있다면) “현재 접속 중” 플러그인에서도 마찬가지일 것입니다.
