초대 링크를 통해 새 사용자가 가입하면, 현재로서는 그 사용자를 수동으로 승인해야 합니다.
이렇게 되면 초대 링크의 본래 의미가 사라집니다. 그냥 포럼 링크를 보내주는 편이 낫지 않을까요?
새 링크, 기존 링크, 단일 사용자, 다수 사용자 등 다양한 상황과 여러 인스턴스에서 테스트해 봤지만, 결과는 모두 동일합니다.
해당 인스턴스들의 /admin/site_settings/category/all_results?filter=must_approve_users 설정이 TRUE로 되어 있습니다. 이 설정이 너무 문자 그대로 적용되는 것 같습니다. 저는 초대 없이 가입하는 사용자만 승인하고 싶습니다. 이전에는 그렇게 작동했었거든요.
must approve users(사용자 승인 필수)를 설정하면 모든 사용자가 명시적으로 승인되어야 한다는 것을 선택한 것입니다.
Discourse 사용자들의 보안 우려로 인해 이 설정을 변경해야 했습니다.
포럼을 “초대 전용” 또는 "로그인 필요"로 변경한 후, 초대할 수 있는 사용자를 제한하는 것이 어떨까요?
스태프의 초대장이 명시적인 승인이라고 생각했어요 - 특히 초대장에 사용자의 이메일 주소가 포함되어 있다면요!
공개 초대 링크의 경우 링크를 악용할 수 있는 기회가 많다는 것은 당연합니다. 하지만 스태프가 해당 링크를 허용하도록 의도적으로 설정해야 하며, 그 위험을 쉽게 책임지고(또는 제한할 수) 있습니다.
이렇게 하면 제 사이트를 우연히 방문한 사람들이 가입할 수 없고, 그들을 초대해 줄 사람을 찾지 못하면 제외됩니다. 이건 별로입니다.
/admin/site_settings/category/all_results?filter=must_approve_users?에 두 가지 옵션을 추가하는 건 어떨까요?
기능 요청 목록에 추가해 드릴 수 있어 기쁩니다. 다만, 현재 여력이 부족해 추가적인 정밀도 개선 작업에 착수하기 어렵습니다.
맞습니다. 다만 이 동작은 약 한 달 전에 변경되었습니다:
저희는 기술 교육용으로 사용 중인 자선 단체/노조의 인스턴스에서도 유사한 영향을 받고 있습니다.
변경 이전에는 스태프가 초대한 사용자가 승인을 우회할 수 있었지만, 이제는 승인 절차와 가입 절차를 모두 거쳐야 합니다. 각 승인 사항을 멤버십 목록과 대조하여 확인해야 하는 번거로움으로 인해 관리 부담이 상당히 증가했습니다.
음 … 장기적인 해결책은 아마도 완화된 승인 모드를 허용하는 사이트 설정을 추가하는 것일 거예요. 선택적으로 활성화하는 방식이죠.
하지만 보안 문제를 여기서 제대로 처리하는 것은 매우 매우 어렵기 때문에 걱정이 됩니다. 허용하는 에지 케이스가 많아질수록 복잡성과 잠재적 보안 취약점도 늘어납니다.
주요 엣지 케이스가 초대 링크에 특정 이메일 주소가 포함된 경우에만 ‘승인 필요’ 사용자 설정을 무시하도록 하고, 익명 초대 링크에는 해당 설정을 유지하는 것일지 궁금합니다. 하지만 백엔드에서 이를 구현하는 것이 내가 상상하는 것보다 더 복잡할 수 있습니다.
저는 이것이 타당하다고 생각합니다. 특히 초대장이 특정 이메일 주소로 발송되었고, 또한 직원으로부터 보내진 경우라면 더욱 그렇습니다. 그런 상황에서는 2차 승인 절차가 필요하지 않을 것이라고 생각합니다.
관리자만 “자동 승인” 플래그를 설정할 수 있도록 하고, 필요에 따라 “변경되지 않은 이메일” 또는 “1개로 제한” 등으로 제한하는 방식은 어떨까요? 제 경우라면, 그러한 특별히 사전 승인된 초대장을 생성할 수 있는 커맨드라인 기반 초대 도구가 있다면 그것만으로도 만족할 것입니다. 이와 유사한 기능이 이미 존재합니까?
아쉽게도 없습니다.
Sam이 제안한 대로 임시 해결책으로 이렇게 해 보았습니다:
저희 포럼에 초대 링크를 꽤 넉넉하게 배포했는데, 그 방식이 잘 작동합니다.
문제는 구글 검색 등을 통해 우연히 사이트를 방문하는 '방문객’들입니다. 가입 링크를 받기 위해 이메일을 보내야 하는데, 관리자에게는 정말 번거로운 일입니다.
Arman의 제안은 꽤 단순한데, 구현하기가 그렇게 어렵지 않을 것 같습니다(또는 보안 구멍이 생길 가능성도 낮을 것 같고요):
이 기능이 구현될 가능성이 있을까요?
현재 must_approve_users가 TRUE인 경우, 단순히 그런 상황이 아닙니다.
사용자 그룹을 초대할 때마다 매번 많은 마찰(승인 단계)을 감수하거나, 사이트를 일시적으로 재구성해야 합니다(이 경우 공개 가입이 차단됩니다). 이는 꽤 고통스러운 과정입니다.
이것이 언젠가 실현될 것에 대해 의견이 있으신가요?
반대하지는 않지만, 아직 일정에 잡히지는 않았습니다.
안녕하세요, 승인 단계를 우회할 수 있는 스태프 초대 기능을 추가해 주셨으면 합니다. 초대 생성 대화창에 선택적 불리언 옵션을 추가하는 방식일 수 있겠네요.
현재 must_approve_users가 설정된 사이트의 경우, "이 링크를 공유하여 사이트에 대한 액세스를 즉시 부여하세요"라는 문구가 전혀 사실과 맞지 않습니다.
해결책은 보안 문제를 수정하는 버그에 대해 논의했던 토픽에서 "옵션 4"로 논의되었던 내용과 같아 보이지만, 이 방법은 초대 링크를 '사전 승인’하는 데 있어 이러한 문제를 남겼습니다.
요약하자면, 이 요청은 must_approve_users 사이트의 스태프가 승인 단계를 우회하는 초대 링크를 생성할 수 있도록 하기 위한 것입니다. 제가 운영하는 사이트는 승인이 필요하지만, 신뢰할 수 있는 개인에게 비공개로 공유될 것을 알거나 포럼 커뮤니티와 관련된 물리적 행사에서 링크를 공유할 때와 같이 때로는 **‘사전 승인’**된 초대 링크를 통해 사용자를 승인하고 싶습니다. (이러한 초대 대상자의 선호 이메일 주소를 항상 알 수 없으므로 대량 초대를 사용할 수 없습니다.)
우리처럼 (좀) 큰 규모로 must_approve_users를 사용하는 사이트에서는, 오프라인 행사를 열 때마다 이 문제가 늘 골칫거리입니다.
문제는 사용자에게 예쁜 QR 코드나 초대장, 또는 인스턴스로 바로 접속할 수 있는 링크를 제공하기가 어렵다는 점입니다. 어색한 우회 방법이 아닌 한 말이죠.
must_approve_users를 끄고 사이트를 invite_only(초대 전용)로 설정하는 것은 다음과 같은 이유로 만족스럽지 않습니다:
많은 사용자가 초대 과정을 잘 처리하지 못하고, (이제 잠긴) '정문’을 통해 들어오려 시도합니다.
행사로 인한 관심은 일반적으로 초대받지 않은 사람들에게까지 퍼지지만, 그들은 가입을 신청할 수도 없습니다.
단계별 사용자(staged users)가 가입할 때 사용자 정의 필드 입력값이 사라지는 버그가 여전히 존재합니다.
변경 이후의 현재 상황은 확실히 모든 것을 훨씬 더 어렵게 만들었습니다. 제가 협력했던 스킬 교육 자선 단체 중 가장 큰 영향을 받은 단체는 몇 주 후 커뮤니티를 폐쇄하기로 결정했습니다.
매주 수백 명의 사람들이 오가고 있을 때, 이는 너무 많은 추가적인 행정 업무 부담이 되기 때문입니다.
다시 이 문제를 언급해 주셔서 감사합니다. 이제 세 번째 규칙(3회 반복)에 도달한 것 같아, 초대 기능을 더 쉽고 매끄럽게 만들기 위해 어떤 수정이 필요하다고 생각합니다. 초대 시스템은 사람들이 각각 다른 방식으로 사용하고 있는 것으로 보아 변경이 까다로운 것으로 입증되었습니다. 명확한 지침을 세우고 기존 워크플로를 깨뜨리지 않도록 주의해야 합니다. 
팀과 상의해서 어떤 조치를 취할 수 있는지 확인해 보겠습니다. 
저에게는 새로운 소식입니다. 이 문제는 별도로 살펴보겠습니다.
제가 볼 때, 마지막 변경 사항에는 설정 항목과 합의된 기본값만 필요했습니다.
모든 직원 초대가 승인 절차를 거치지 않던 것에서 모든 초대가 승인을 요구하도록 바뀌었습니다.
너무 쉽다는 식으로 말씀하시네요! 
우리가 우려하는 점은 사이트가 다양한 방식으로 설정될 수 있고, 이에 따라 초대 시스템도 다르게 작동하기를 기대한다는 것입니다. 보안은 매우 현실적인 우려 사항입니다. 따라서 초대 시스템에 추가적인 변경 사항을 적용할 때 신중하게 접근할 것입니다.
개인적으로 다음 접근 방식이 가장 적절하다고 생각합니다. 이 방식은 관리자 설정에 의존하지 않으며, 초대 모달에서 동작 방식을 명확하게 보여주기 때문입니다. Discourse를 처음 사용하는 사람조차도 의도하지 않은 동작을 수행하는 초대 링크를 우연히 생성하고 공유할 가능성이 거의 없습니다. 여러분은 어떻게 생각하시나요?
must approve users(사용자 승인 필요) 관리자 설정이 활성화된 경우[ ] 스태프 승인 불필요이 토글에 대한 접근 권한은 스태프에게만 있어야 한다는 전제가 있습니다. must approve users 설정의 의도는 커뮤니티 가입을 허용할 대상에 대한 통제를 스태프에게 부여하는 것이기 때문입니다.
충분한 수요가 있다면, 추후 이 기능에 대한 접근 권한을 그룹별로 결정할 수 있는 관리자 설정을 추가하는 것을 고려할 수 있습니다.
샘은 이 변경 사항을 놀랍도록 복잡하다고 표현할 정도였습니다. 그의 말을 믿지 못할 이유가 없습니다.
원래 변경 사항과 이번 변경 사항을 합친 총 노력량은 처음부터 이를 고려하지 않았던 것보다 분명히 더 클 것입니다. 당시 우리는 한 커뮤니티가 현재 기본 설정에 문제를 제기한 반면, 이 동작에 의존하는 여러 커뮤니티가 존재한다는 점을 확인했습니다. 예를 들어, 디스코르스(Discourse) 기반의 스킬 훈련 사이트를 포기한 조합은 이 결정을 가볍게 내린 것이 아니었지만, 직원들이 초대한 수료생들이 일반 승인 풀에 섞여 들어가는 상황이 발생하자 계속 유지하는 것은 비현실적이었습니다.
여기서의 문제가 명시적인 이해 부족이었다면, must approve users(사용자 승인 필수)와 초대 모달 사이에 직원의 초대가 승인을 우회할 수 있는 옵션을 제시하는 중간 단계가 필요할 것입니다. 그렇지 않으면 이 변경 사항으로 이어진 원래의 불만이 다시 발생할 수 있습니다.
즉, 다음과 같이 더 구체적으로:
must approve users 관리자 설정이 활성화되어 있고, 새로운 staff invites bypass approval(직원 초대 승인 우회) 설정이 기본값인 never(절대)에서 변경될 때:always(항상)로 설정하면 이전 동작이 적용됩니다.optional(선택)로 설정하면 모달에 스위치를 표시하여 이후 승인을 우회할 수 있는 옵션을 제공합니다.이 중간 단계가 없으면 관리자는 '승인 필수’의 함의를 완전히 인지하지 못할 수 있으며, 토글 사용을 잊어버리는 다른 문제를 해결하기 위해 약간의 세밀한 설정이 필요합니다.
이 방식이 정말 잘 작동할 것 같다고 생각합니다(아마도 @Stephen의 조정 사항과 함께라면 더욱 그럴 것입니다). 기본 구조를 완전히 그대로 두므로 아무것도 깨지지 않을 것이며, 개인 중심의 접근 방식이라 좋게 생각합니다.
그러나 저에게는 매우 중요한 경계 사례가 하나 있습니다. 바로 그룹 초대와 관련된 자동 이메일 초대입니다. 이 기능은 사용자가 이미 가입했는지 여부에 따라 단일 관리자 작업으로 사용자를 그룹에 추가하거나 초대를 보낼 수 있게 해줍니다. 개인적으로 이 부분도 어떻게든 커버되기를 정말로 바랍니다.