기존 시스템에 Discourse를 통합하여 Discord 서버에 대한 의존도를 줄이고자 합니다. 우리는 이미 자체 계정 시스템을 갖추고 있으며, 마찰을 줄이기 위해 이를 재사용하고 싶습니다. 다만, 우리 시스템에서는 이메일 주소가 고유할 필요가 없으며, 사용자 이름만 고유하면 됩니다. Discourse는 이메일이 전역적으로 고유하다는 가정에 의존하고 있어 직접적인 통합이 불가능해 보입니다.
하지만 나중에 OAuth 소스에서 이메일이 제공되지 않는 경우, 사용자가 나중에 수동으로 이메일 주소를 입력해야 한다고 언급하고 있습니다:
이메일 경로를 생략했습니다: SoundCloud는 이메일을 제공하지 않으므로, 사용자가 Discourse에 처음 가입할 때 이메일을 제공하고 확인해야 합니다
우리의 경우에도 Discourse를 사용하는 것이 여전히 실행 가능한가요? 사용자가 Discourse에 처음 로그인할 때 이메일 주소를 수동으로 제공하도록 하는 것은 우리에게는 문제가 되지 않습니다. 단, 실제 로그인 과정에서 이메일 주소를 사용하는 기능을 비활성화할 수 있어야 합니다(사용자 이름과 비밀번호만 사용하도록 요구). 이메일을 고유한 사용자와 신뢰할 수 있게 매핑할 수 없기 때문입니다. 로그인 폼에서 이메일 사용 기능을 완전히 비활성화할 수 있다면, 우리는 이를 지원할 계획이 없으므로 마찰이 줄어들고, 사용자가 시도조차 하지 않도록 방지할 수 있어 좋습니다.
이점에 대해 검토해 보았지만, OAuth 플로우에 어떤 영향을 미칠지, 또는 가입/로그인에 마찰을 유발할지 확신이 서지 않았습니다. 이러한 변경 사항은 사용자에게는 보이지 않으므로, 사용자가 수정된 이메일 주소를 입력하지 않는 한 로그인에 실패하게 될 것입니다. 또한 현재 계정 서버는 이러한 수정 사항을 인식하지 못하므로, 사용자가 수정된 이메일을 입력하더라도 우리 기록에서 해당 정보를 찾을 수 없게 되지 않을까요?
이미 이메일 별칭을 사용 중인 사용자들의 경우에도 이 변경 사항이 문제를 일으키게 되지 않나요?
음, 그렇습니다. 당연히 그런 경우일 것이고, 제가 목표로 하는 것도 바로 그 부분입니다. 저는 이메일 로그인을 아예 허용하지 않고, 사용자 이름 로그인을 유일한 방법으로 남기는 해결책을 찾고 있었습니다. OAuth 서버에서 완전히 가짜 이메일을 제공하여 이메일 지원을 사실상 완전히 깨뜨리는 것(예: 이메일 알림 없음)에는 문제가 없습니다. 하지만 이메일로 로그인할 수 있는 기능이 여전히 사용 가능하면, 사용자가 이를 시도했다가 실패하게 되어 마찰이 생기기 때문입니다.
그것은 기본적으로 사용자에게 2개의 서로 다른 이메일 주소를 추적하게 만들며, 이는 바람직하지 않습니다. 또한 @supermathie가 언급했듯이 모든 제공업체에서 작동이 보장되지 않으며, 사용자가 기억해야 하는 이 포럼 전용 이메일 주소를 알려주어야 하므로 여전히 마찰을 유발합니다.
네, 기술적으로는 작동할 것입니다. 하지만 명백한 이유로 인해 실제 해결책으로 사용할 수 없으며, 다른 모든 사용자가 포럼에 가입하는 것을 영원히 차단하게 될 것이기 때문입니다.
이것은 기술적인 이유로 우리가 할 수 있는 일이 아닙니다. 가장 명백한 이유는 이미 다른 계정과 동일한 이메일 주소를 가진 사용자가 있다는 점입니다. 하지만 더 큰 이유는 우리가 단순히 이를 수행할 수 없다는 것입니다. Discourse를 통합하려는 프로젝트는 Pretendo Network로, Nintendo Network를 위한 서버 에뮬레이션 프로젝트입니다. Nintendo는 계정 시스템에서 이메일 주소를 재사용하도록 허용했으며, 따라서 서버를 정확하게 에뮬레이션하려면 우리도 그렇게 해야 합니다. 고유한 이메일을 강제하는 것은 우리에게 불가능한 일입니다.
팀의 누군가는 가짜 이메일을 실제 사용자 이메일로 매핑하는 자체 SMTP 서버를 실행하여, Discourse에서 보낸 이메일을 그렇게 전달하라고 제안했습니다. 이는 작동할 수 있지만, 당연히 우리에게 더 높은 기술적 비용을 수반하며, 또한 이메일 로그인을 비활성화하는 문제와 우리의 경우에 따르는 aforementioned 마찰을 해결하지는 못합니다.
우리가 필요한 일을 수행하기 위해 Discourse를 포크하거나 다른 포럼 솔루션을 사용해야 할 것 같습니다.
기억에 의존해서 말하지만, 가상이지만 고유한 이메일 주소를 사용하여 DiscourseConnect를 사용할 수 있습니다. 사용자 이름이 귀사의 시스템에서 고유하게 보장된다면 구현은 매우 간단할 수 있습니다. 이메일 주소는 username@invalid.com과 같은 값으로 설정할 수 있습니다.
사용자들은 현재 사용 중인 방식으로 귀사의 시스템에 로그인합니다. 그러면 귀사의 시스템이 가상의 이메일 주소를 포함하여 SSO 페이로드를 생성합니다.
이 방식의 단점은 Discourse에서 이메일 기능을 비활성화해야 한다는 것입니다. 이는 disable emails 설정을 yes 또는 non-staff(관리자 멤버들이 고유한 이메일 주소를 가진 경우)으로 설정하여 수행할 수 있습니다.
중복된 이메일 주소를 가진 사용자를 위해 + 기반 이메일 주소를 사용하는 것도 고려해 볼 수 있습니다. 마지막으로 확인했을 때, Discourse는 + 기반 이메일 주소를 고유한 것으로 취급했습니다. DiscourseConnect 페이로드에 이메일 주소를 사용하기 전에 URL 인코딩을 수행했는지 반드시 확인하세요. 여기서의 위험은 사용자가 중복된 이메일 주소를 가지고 + 기반 이메일 주소를 지원하지 않는 이메일 서버를 사용하는 경우, 해당 사용자는 Discourse에서 이메일을 받지 못한다는 것입니다. 하지만 이렇게 하면 다른 사용자들이 Discourse 이메일을 받을 수 있게 됩니다.
네, 하지만 특정 경우에 한합니다. 사용자가 Discourse 사이트에서 DiscourseConnect를 구현하기 전에 Discourse 계정을 생성한 경우, Discourse는 DiscourseConnect 페이로드에 있는 이메일 주소와 기존 사용자를 연관시키려 합니다. 새로운 Discourse 사이트를 시작하는 경우라면 문제가 되지 않습니다.
이메일 매핑 문제가 발생한 다른 한 가지 사례는 인증 제공자 사이트의 잘못된 코드 때문에 Discourse 사이트의 SSO 기록이 손상된 경우였습니다. 그 경우, 사이트는 Discourse 쪽에서 모든 SSO 기록을 삭제한 다음, 사용자가 다음 로그인할 때 Discourse가 사용자를 SSO 페이로드의 이메일 주소와 연관시키도록 했습니다. 그런 다음 Discourse는 사용자들을 위해 새로운 SSO 기록을 생성했습니다. 이 방식은 가상의 이메일 주소를 사용해도 여전히 작동합니다.
DiscourseConnect 인증의 논리는 다음과 같습니다. Discourse는 먼저 페이로드의 external_id 필드를 기반으로 사용자를 찾으려 하고, 사용자를 찾지 못하면 페이로드의 email 필드를 기반으로 사용자를 찾으려 하며, 그래도 사용자를 찾지 못하면 오류를 발생시킵니다.
실제 라이브 사이트에 구현하기 전에 이 모든 것을 다시 한번 확인하세요. 하지만 가상의 이메일 방식이 사용자의 실제 이메일 주소를 Discourse 사이트와 공유할 수 없는 경우에 프로덕션 사이트에서 사용된 적이 있다는 것을 알고 있습니다.
이것은 괜찮습니다. 그리고 저는 이전에 이것이 "모든 이메일이 고유해야 한다"는 문제에 대해 허용 가능한 해결책이라고 언급한 바 있습니다. 저희의 경우 이메일을 사실상 비활성화하는 것에 대해 전혀 문제없으며, 가짜 이메일을 사용하는 것은 이 게시글을 작성하기 전에 제가 이미 도달했던 해결책이었습니다.
처음부터 명확하지 않았을 수 있지만, 이 게시글의 목적은 로그인 프롬프트가 사용자 이름만 받도록 강제할 수 있는지 확인하는 것이었습니다. 현재는 사용자 이름이나 이메일 중 하나로 로그인이 가능하기 때문입니다. Discourse의 로그인 프롬프트에서 이메일 로그인이 여전히 사용 가능한 것으로 표시된다면, 사용자는 기존 계정 이메일 주소를 사용하려고 시도하다가 오류를 마주하게 될 수 있습니다. 따라서 사람들이 현재 이메일 주소를 사용하려고 시도하고 실패하는 상황을 그냥 감수하거나, 사용자에게 새로운 포럼 전용 이메일 주소를 알리는 방법 중 하나를 선택해야 합니다. 이 두 가지 모두 사용자에게 혼란과 마찰을 초래할 수 있으므로, 이상적으로는 로그인 프롬프트가 사용자 이름만 받도록 제한할 수 있으면 좋겠습니다.
불행히도 직원들이 고유한 이메일 주소를 가진 것도 보장되지 않으므로, 저는 이것에 의존하고 싶지 않습니다. 이 설정은 이메일 전송만 비활성화하나요? 아니면 제가 로그인 프롬프트에서 원하는 것과 같이 이메일 사용 자체를 모두 비활성화하나요?
DiscourseConnect 페이지를 여러 번 살펴봤지만, 거기서 해당 옵션을 볼 수 없었습니다. 이런 종류의 문서를 볼 수 있는 더 나은 곳이 있을까요? 그 게시글에 전체 문서에 대한 링크를 찾지 못해서, 거기에 있는 정보가 전부인 줄 알았습니다.
솔직히 말씀드리면, 저는 실제로 DiscourseConnect를 설정해서 설정값을 파헤쳐 본 적이 없습니다. 문서만으로도 무엇이 가능하고 불가능한지 파악할 수 있기를 바랐고, 그렇게 하지 않으면 포럼의 전체 테스트 인스턴스를 설정해야 할까 봐 우려했습니다. 하지만 여전히 쉽게 찾을 수 없는 정보가 있는 것 같습니다. 제가 뭘 놓친 건가요?
이것도 이 스레드에서 이전에 고려되었지만, 여전히 실패한 이메일 로그인을 처리하거나 사용자에게 이 새로운 포럼 이메일 주소를 알려야 한다는 문제가 남아 있습니다. 그 마찰을 제거하는 것이 제 주요 목표였습니다. 만약 Discourse 자체를 포크하지 않고서는 이것이 불가능하고, 유일한 해결책이 실패한 이메일 로그인을 처리하거나 사람들에게 기억해야 할 새 이메일을 주는 것이라면, 다른 포럼 솔루션이 더 나을 수도 있습니다.
제 이해가 잘못된 것 같습니다. 게시글 자체를 바탕으로 볼 때 그 부분이 아주 명확하지는 않습니다. 하지만 제가 그 점을 언급한 이유는 이메일의 고유성에 대한 의존성을 보여주기 위해서였으며, 이는 여전히 문제가 될 것입니다.
게시글만으로는 이것이 절대 명확하지 않았습니다. 제가 뭘 놓친 게 아니라면요. 그 설명에 감사드립니다! 제가 희망했던 것과 더 일치하는 것 같습니다.
제가 아는 한, Discourse 로그인 프롬프트에서 사용자 이름 필드만 표시하도록 강제하는 것은 불가능합니다. 또한 사용자가 처음에 어떻게 등록되는지 파악하는 데도 막힐 수 있습니다. 그래서 저는 DiscourseConnect 사용을 제안합니다.
DiscourseConnect가 활성화되면, 이는 Discourse 사이트의 유일한 인증 시스템이 됩니다. 사용자가 Discourse에서 로그인 버튼을 클릭하면, discourse_connect_url 사이트 설정에 추가한 URL로 자동으로 리디렉션됩니다. 이후 인증 시스템이 인계됩니다. 즉, 현재 사용자가 사용자 이름과 비밀번호로 로그인할 수 있는 사이트가 있다면, 앞으로도 같은 방식으로 로그인할 수 있습니다.
현재 사이트에 코드를 추가할 수 없는 경우, 사용자가 사용자 이름과 비밀번호로 로그인할 수 있는 작은 웹사이트를 만든 후, 그 사이트에 DiscourseConnect 코드를 추가하는 방법도 있습니다. 이는 Discourse를 포크하는 것보다 훨씬 적은 작업이 필요합니다.
아니요, 변경하지 않았습니다. 앞서 말씀드린 것처럼, Discourse가 사용 가능한지 확인하기 전까지는 테스트 배포를 진행하지 않으려고 했습니다. 그래서 실제로 아무것도 시도해 보지 않았고, 지금까지는 단순히 기능들을 읽어보며 명확하지 않은 것들이 있으면 여기에 질문하는 정도였습니다. 사실 그 정도까지 제어할 수 있다는 것은 정말 놀라운 소식입니다. 저는 그 사실을 알지 못했거든요.
솔직히 말하면, API를 제외하고는 실제 문서를 찾는 것이 꽤 어렵습니다. 적어도 처음 사용하는 사용자의 관점에서는 그렇습니다.
이 모든 것이 다루어지는 명백한 장소가 있는데 제가 놓친 것일까요? 제가 찾을 수 있는 가장 가까운 곳은 포럼 카테고리인 것 같습니다. 스태프 등이 다양한 주제에 대한 가이드나 how-to를 많이 작성해 두었기 때문입니다. 하지만 포럼을 재사용하여 자체를 문서화하는 방식은 제게는 적절해 보이지 않았습니다. Discourse API처럼 Discourse 기능/도구를 위한 전용 문서 소스가 없는 건가요?
맞습니다, 그 방법은 작동할 것입니다. 여러 번 언급했듯이, OAuth 제공자에서 가짜 이메일을 사용하는 것은 이 게시글을 작성하기 전에 이미 생각해 낸 방법입니다.
하지만 그것만으로는 "로그인 프롬프트에서 이메일이 허용된다는 것을 본 사용자가 이를 시도하다가 가짜 이메일을 가지고 있어 실패한다"는 문제를 해결하지는 못합니다.
그러나 저는 방금 DiscourseConnect가 어떻게 작동하는지에 대해 오해하고 있었다는 것을 깨달았습니다. 로그인 양식이 여전히 디스커스에 있고, 디스커스가 단순히 OAuth 제공자에게 요청을 보낸다고 생각했습니다. @simon 님이 이 부분을 바로잡아 주셨는데, 사용자가 물리적으로 사이트 밖으로 이동하여 저희의 자체 로그인 양식을 사용한다는 사실을 몰랐습니다. 이것만으로 제가 가진 대부분의 문제가 해결되었습니다. 감사합니다!
제가 함께 일해 본 사람들 중 discourse.org 호스팅에 불만을 가진 사람은 없습니다. 어떤 이유로든 셀프 호스팅이 필요하시다면 https://dashboard.literatecomputing.com/ 에 로그인하여 “무료 트라이얼” 그룹에 가입하고 대시보드를 무료로 사용하실 수 있습니다(무료 트라이얼 그룹에 가입하는 방법을 모르겠다면, 제가 제공할 수 있는 지원 수준을 넘어선 도움이 필요할 가능성이 높습니다). Digital Ocean과 mailgun을 사용하시기로 하셨다면, API 키와 호스트명만 입력하면 됩니다.
부끄럽게도 이 옵션을 생각조차 하지 못했습니다! 좋은 지적이었고, 테스트 목적으로 이 방법을 진행해 볼 가능성이 높습니다.
오늘早些에 호스팅 옵션을 살펴봤는데, 자체 호스팅보다 편할 것 같았지만, 불행히도 예산 범위를 크게 벗어나는 것 같습니다. 저희는 20만 명 이상의 사용자를 보유하고 있어 “Basic” 플랜은 선택지가 아닙니다. 직원 수가 5명을 초과하므로 “Standard” 플랜도 선택지가 아닙니다. 또한 FOSS 프로젝트로 기부에 의존해 운영되고 있어, 전기세와 풀타임 개발자 1명의 급여를 감당할 정도로 간신히 수입을 올리고 있을 뿐이라 “Business” 플랜은 매우 부담이 큽니다.
그러나 테스트 목적으로 트라이얼을 사용하는 것은 훌륭한 아이디어입니다, 감사합니다! 어쨌든 저희는 대부분의 서비스를 자체 호스팅하고 있으며, 마스토ドン(Mastodon) 인스턴스까지 포함하고 있으므로, 디스커스(Discourse)를 자체 호스팅하는 것은 큰 장벽이 아닙니다.
물론이죠! 도움이 될 수 있다면 항상 기꺼이 도와드리고 싶습니다, 피드백을 드리는 것만으로도요. 너무 부정적으로 느껴지지 않았기를 바랍니다. 본래 그런 의도는 아니었으니까요.
감사합니다! 가격 페이지에서 이 내용을 놓치고 있었습니다. 다시 가서 확인해 보니 페이지 맨 아래에 깊이 묻혀 있네요 이 내용을 검토하고 저희 팀원들과 상의하겠습니다!
이 경우 저희가 말하는 "staff"의 정의는 두 가지 광범위한 역할을 포함합니다:
핵심 개발 팀의 사람들 (오픈 소스 프로젝트이므로 사람에 따라 변동이 있을 수 있지만, 지난 몇 년간 항상 5~10명의 활동적인 개발자가 있었습니다)
모더레이션 팀 (개발자가 아니면서 서비스(온라인 매치, Miiverse 구현 등) 및 Discord 서버를 관리하는 커뮤니티 멤버들). 이 부분도 변동이 있습니다
저희는 개발자 5명으로만 제한하여 한도에 맞출 수 있지만, 그렇게 하려면 포럼에서 완전한 권한을 부여할 사람과 부여하지 않을 사람을 결정해야 합니다. 또한 포럼을 관리할 수 있는 사람의 수도 제한됩니다 (저희는 처음부터 이 부담을 개발 팀에만 맡기지 않기 위해 개발 팀 외부에 모더레이션 팀을 도입했습니다)
이 내용을 검토하고 저희 팀원들과 상의하겠습니다!