이 주제와 이전 주제들을 읽어보면서, 현재 동작 방식이 의도된 설계(by design)라는 것을 알 수 있지만, 초대 시스템의 새로운 변경 사항을 반영하지 못하고 있음을 확인했습니다. 이제 모르는 사람들이 사용할 수 있는 초대 링크를 생성하는 것이 훨씬 쉬워졌습니다. 또한 이제 스태프가 초대 대상자를 사이트의 보안 카테고리 접근 권한이 있는 그룹에 추가할 수 있는 위험한 초대 링크를 생성할 수도 있습니다.
@Wall-E 초대 링크가 사이트 접근 권한이 없는 사람들의 손에 넘어가는 구체적인 상황이 어떻게 되는지 궁금합니다. 아마도 사이트 스태프는 누구나 사용할 수 있는 초대 링크를 생성하거나, 잘못된 사람들이 이를 사용할 수 있는 환경에서 공개적으로 공유하지 않도록 주의해야 한다는 점을 알고 있을 것입니다. 따라서 현재 직면하고 있는 문제는 어느 정도 스태프 교육의 문제라고 볼 수 있습니다. 민감한 세부 사항이 포함된 답변이라면 편하게 DM으로 보내주세요.
현재 존재하는 초대 링크 중 어떤 식으로든 유출된 것이 있다면, 이를 삭제하고 새 링크를 생성한 후 앞으로는 더 신중하게 공유할 수 있습니다. 관리자라면 사용자 초대 페이지에서 누가 초대를 사용(redemption)했는지 항상 확인할 수 있습니다. 신뢰할 수 없는 스태프가 있다면, 그 권한을 TL4(거의 모더레이터 권한)로 낮출 수 있습니다.
세 가지 가능한 대응 방안을 제시합니다:
- 아무것도 하지 않습니다. 초대 시스템은 의도된 대로 작동하고 있으며, 스태프가 초대 링크를 신중하게 다루면 됩니다. 이 방향으로 간다면,
must approve users관리자 설정의 설명을 변경하여 관리자가 생성한 초대 링크가 이 설정을 우회한다는 점을 명확히 하는 것이 좋습니다.
스태프는 사용자가 사이트에 접근할 수 있도록 하기 전에 모든 새로운 사용자 계정을 승인해야 합니다. 참고: 스태프가 생성한 초대는 이 설정을 우회하며 승인이 필요하지 않습니다.
이 변경 사항에 대한 Pull request는 여기에 있습니다: clarify that invites by staff bypass user approval - Pull Request #16966 - discourse/discourse - GitHub
-
(1)과 함께, 승인(approval)이 필요한 사이트에서만 사이트 접근 권한을 즉시 얻을 수 있는 초대 링크를 생성할 때 관리자에게 "확실합니까?"라는 추가 경고 단계를 추가합니다.
-
관리자가 생성한 초대 링크도 비관리자의 초대와 마찬가지로 승인 필요(approval required) 설정을 따르도록 동작을 변경합니다.
OP와 마찬가지로, 현재 동작 방식이 오해의 소지가 있으며, 승인(approval)이 필요한 사이트에서 문제를 초래할 가능성이 있다고 생각합니다. 이 설정을 활성화한 사이트는 접근 권한이 있는 사람에 대해 더 신중하고, 이러한 추가적인 편집증적 수준의 통제가 필요합니다.
따라서 제 추천은 세 번째 문(Door number three)을 선택하여 모든 초대 링크가 동일하게 작동하도록 하고 must approve users 설정을 따르도록 하는 것입니다.
이것은 버그라고 생각하지 않습니다. 의도된 대로 작동하고 있습니다. 기능 요청(feature request)으로 재분류합니다.