Per:
invite_code라는 이름의 새로운 옵션 설정이 추가되었습니다.
이 값이 설정되면, 모든 계정 생성 시 초대 코드를 입력해야만 계정 생성이 허용됩니다. 이 코드가 없는 사용자는 계정을 등록할 수 없습니다.
초대 코드가 잘못 입력된 경우, 사용자에게 유용한 오류 메시지가 표시됩니다:
이 기능은 100% 선택 사항입니다! 현재는 로컬 인증(local auth)과만 호환되지만, 향후 업데이트에서 이를 개선할 예정입니다.
전역 초대 코드를 활성화하면 해당 설정이 적용되고, 활성화하지 않으면 적용되지 않으며 등록 대화창에 초대 코드 입력란이 표시되지 않습니다.
이것이 어떻게 말이 됩니까? 코드가 스태프의 신규 계정 승인을 우회할 수 있도록 허용해야 하지 않나요?
이 코드는 스태프/비스태프에 관한 것이 아니라 100% 새로운 계정 등록에 관한 것입니다.
사용 사례는 WhatsApp이나 Facebook의 비공개 그룹에 게시하는 것입니다.
안녕하세요, 여러분을 위한 포럼을 설정했습니다. “Welcome to Discourse” 초대 코드를 사용하여 계정을 등록해 주세요.
사이트가 등록을 요구하므로, 해당 코드를 가진 사람만 접근이 허용됩니다.
확장할 수는 있지만, 이 부분에 대해 매우 시급한 사용 사례가 있어 오늘 이 작업을 완료했고, 다음 주에 개선할 예정입니다.
이 기능의 사용 사례를 정말로 전혀 이해하지 못하겠습니다.
새 계정 승인 기능을 활성화하고 사람들에게 해당 사이트를 안내하면 안 될까요?
이 설정은 각 계정에 대한 수동 검토를 필요로 합니다. 이 설정은 소수의 사용자로 테스트를 해보려는 사용자나, 포럼 접근을特典으로 제공하는 프로모션을 진행 중인 분들에게 정말 유용합니다. 이러한 초대 코드는 파일럿 프로젝트 포럼의 업무 부담을 거의 극적으로 줄여줄 것입니다.
모든 이메일을 하나하나 승인해야 하고, 승인 대기열에 24시간 365일 붙어 있어야 하는데, 이렇게 등록한 랜덤 봇이 실제로 접근 권한을 가져야 할 사람인지 전혀 알 수 없기 때문입니다.
초대 코드가 있으면, 적어도 내가 비공개로 공유한 초대 코드를 가지고 있다는 사실은 알 수 있습니다.
그런데 그게 바로 사용자 승인 기능의 핵심이 아닌가요?
이것은 우리의 코로나19 대응 플랫폼에도 도움이 될 것입니다 - 네, 가능한 한 빨리요!!!
이 기능에 +1입니다. 제가 운영하는 여러 커뮤니티에서 매우 유용합니다. 위 @codinghorror님과 @ondrej님이 언급한 수동 승인에 대한 점은 이해하지만, 이 기능은 ‘초대 전용’ 사이트에서 모든 사람을 수동으로 초대하는 것과 ‘승인’ 사용자 사이트에서 모든 사람을 수동으로 승인하는 것 사이에 존재하는 공백을 메워준다고 생각합니다.
사용자를 승인하는 것은 원하지 않습니다. 그냥 슬랙/텔레그램/왓츠앱 그룹에 코드를 올리고 누구나 사용할 수 있게 하면 됩니다. 정식 출시 전에 몇 명만 먼저 테스트하게 하는 것은 큰 문제가 되지 않습니다.
네, 이 기능이 지금은 정말 큰 도움이 될 것 같아요! 
저도 이 기능이 매우 유용하다고 생각합니다. 특히 기능을 약간 확장하여 특정 초대 코드에 그룹을 "연결"할 수 있도록 하면, 특정 코드로 계정을 생성한 사용자가 자동으로 해당 그룹에 추가되는 방식이 가능해지거든요.
일부 사용 사례에서는, 간헐적으로 제기되는 이메일과 무관한 초대 토큰에 대한 요구사항도 이 방법으로 해결할 수 있을 것입니다…
이것이 왜 다음 문장과 실질적으로 다른가요?
적어도 내가 개인적으로 공유한 URL을 가지고 있다
솔직히 현재 이 기능이 어떻게 작동하는지 정말로 이해가 되지 않습니다.
우회 코드 입력 또는 관리자 승인 중 하나를 선택할 수 있는 옵션이 여기서는 가장 합리적입니다.
나는 이 방식이 약간 다른 형태로도 마음에 들어. 다만 조금만 더 다듬으면 좋겠어. 지금 시급한(?) 필요가 있다면, 그렇게 해도 괜찮을 것 같긴 하지?
다만 개인적으로는 마법 도메인 …
https://forum.this-is-my-magic-domain.org에서 가입해 주세요
은 마법 비밀번호 …
이 사이트에 접근하려면 비밀
this-is-my-magic-password을 알아야 합니다
에 비해 가입 보호 수준이 완전히 쓸모없고 전혀 작동하지 않는다고 느끼진 않아.
아래 두 가지 방식 모두 적극적으로 지원할 수 있어 매우 기쁩니다.
amazing.forum.com에 접속하여 초대 코드fantastic를 입력하면 접근할 수 있습니다 (구현 완료)
그리고
amazing.forum.com/register?code=fantastic에 접속하여 가입하면 포럼에 접근할 수 있습니다
이 문제를 해결하는 일반적인 방식인 HTTP 기본 인증(Basic Auth) 뒤에 사이트를 두는 점을 고려할 때, 여기서 100이라는 규칙을 넘은 것 같습니다.
두 방식은 꽤 유사하지만, 당장은 #1을 구현하고 #2는 후속으로 진행할 예정입니다.
#1의 장점은 복사-붙여넣기에 의존하지 않아도 되는 경우가 조금 더 쉽다는 점입니다. 예를 들어 WhatsApp으로 지시를 받고 데스크톱에서 작업을 완료하는 경우처럼요.
#2의 장점은 fantastic을 직접 입력할 필요가 없다는 점이며, WhatsApp 공유보다는 이메일 공유에 유용합니다.
forum.this-magic-domain.org가 어디서 나왔는지 궁금하신가요? 두 경우 모두 포럼이 있는 도메인과 정확히 동일합니다.
이 기능의 UI가 어떻게 보일 것 같다고 생각했는지 간단히 목업해 봤습니다:
(이것은 이메일 인증 후, must_approve_users가 켜져 있는 개발 사이트에서 촬영한 것입니다)
가입 시에도, 승인되지 않은 상태의 로그인 시에도 선택 사항이어야 합니다. 모든 사용자가 코드를 복사해서 전달하도록 강제하는 것은 문제가 발생하고 관리자 개입이 필요하게 될 것이기 때문입니다.
아니요, 누출이 보장됩니다. https://www.farsightsecurity.com/technical/passive-dns/passive-dns-faq/#q11
이것은 기간이 정해진 설정에는 작동할 수 있지만, 장기적인 보안 태세로는 사용할 수 없습니다.
이미 계정을 만들었는데 왜 승인 코드가 필요한가요?
그건 봇이 쓸모없는 계정을 등록하게 두는 건데, 그렇게 하면 데이터베이스가 오염되기 훨씬 전에 제거할 수 있는 거 아닌가요?
게다가 계정은 이미 등록되어 있고, 이미 인증이 완료되었을 수도 있습니다.
또한, 이 비밀 도메인에 대한 논쟁은 대체 어디서 나온 건지 모르겠네요.
예를 들어 메타에서 이 기능을 활성화한다고 가정해 보면:
meta.discourse.org에 접속하여 HELLOMETA 코드를 입력하고 계정을 생성하세요.
이제야 전 주제에서 @codinghorror 님이 지적하신 내용을 우연히 반복해서 말했음을 깨달았습니다. (작성 당시 #feature:announcements 채널에 있었기 때문에 해당 주제를 읽지 못한 상태였습니다.)
결론적으로, 이 기능은 완전히 별개의 시스템을 만드는 대신 must_approve_users + login_required 위에 구축되어야 합니다. 현재 구현 방식은 현재의 위기를 넘기기 위한 임시 해킹(hack)으로는 괜찮지만, 추후에 정리되어야 합니다.
컨퍼런스에서 코드를 제시하면 누군가는 그 코드를 잊어버리거나 기록하지 않을 수 있습니다. 혹은 컨퍼런스 영상이 올라간 후에는 코드를 변경해야 합니다. 이런 경우, 왓츠앱 그룹에서 "@test3 계정은 누구 계정이죠?"라고 물어본 뒤 확인을 받고
버튼을 클릭하는 것이, 가입 폼에 코드를 올바르게 복사해서 입력하도록 설득하는 것보다 훨씬 낫습니다. (참고: 이 스크린샷들은 이메일 인증 이후의 것입니다.)
전체적으로 괜찮다고 생각합니다. 이제 세부적인 조정만 하면 될 것 같아요. 여기서 제가 전적으로 지지하는 몇 가지 개선 사항이 분명히 있습니다.
첫째, 사용자 초대 페이지와의 통합입니다. 예를 들어 https://meta.discourse.org/signup?u=codinghorror 링크를 통해 메타 사이트에서 가입하면, 제 사용자 프로필 페이지에서 제가 초대한 사람으로 표시되죠. 다음과 같이요:
이메일 기반 초대 기능은 이미 초대된 사용자에게 TL1(신뢰 수준 1)을 부여하고 있습니다. 즉, 그 혜택은 이미 존재하는 것이죠. 초대 대화 상자를 확인해 보세요. 그룹 접근 권한을 추가할 수도 있고, TL 상승은 암묵적으로 적용됩니다. 사실 이 대화 상문의 문구에서 이를 명확히 밝혀야 할 것 같습니다:
둘째, 위와 같이 
이메일 없이 초대 링크를 생성할 수 있어야 합니다. 이는 "상대방의 이메일 주소를 모르는데 
"라는 문제를 완전히 해결해 줍니다.
셋째, 사이트가 "초대 전용"인 상태에서 초대가 모두 하이퍼링크와 비밀 비밀번호의 형태로 이루어지는 것은 괜찮다고 생각합니다. 이렇게 하면 다음과 같은 방식이 됩니다.
open sesame)사이트에 승인 절차가 있다면, 비밀 비밀번호를 통해 승인 절차를 건너뛸 수도 있습니다. 승인 절차가 없다면, 비밀 비밀번호 없이는 진입할 수 없겠죠.
제 주요 우려는 기존 기능과 통합하지 않고, 난해한 사이트 설정을 통해 아무 관련 없는 기능을 붙여 넣는다는 점입니다. 하지만 통합을 통해 초대 기능이 이상한 독립형 사이트 설정이 아니라 더 나은 기능으로 발전할 수 있도록 할 수 있습니다.