안녕하세요,
저는 Discourse 관리/개발에 처음 입문했으며, 아직 Ruby를 사용하지 않습니다(물론 배우려는 의지는 100% 있습니다). 제 첫 과제는 Discourse 설치 환경 구축이었고, Digital Ocean에서 공식 Docker 이미지를 사용하여 이를 완료했습니다. 지금까지는 순조로웠습니다 — 이렇게 쉽게 설치할 수 있게 해 주신 분들에게 감사드립니다!
다음 과제는 저에게 더 도전적입니다. 저는 비영리 단체의 Discourse 설치를 자원하여 맡게 되었으며, 이 단체는 사용자 등록과 참여를 해당 단체의 회원으로 제한하기를 원합니다. 따라서 저는 새 사용자 생성 프로세스를 수정하거나, 이 프로세스에 후킹을 하거나(또는 대체하거나?) 제출된 이메일 주소가 기존 단체의 현재 회원 이메일과 일치하는지, 그리고 회원의 만료일이 미래에 해당하는지를 프로그래밍 방식으로 확인해야 합니다.
해당 단체는 NeonCRM을 사용하며, 이를 통해 이러한 검증을 비교적 쉽게 수행할 수 있는 API를 제공합니다. 제 이해로는 Discourse도 수동으로 수행할 수 있는 모든 작업을 수행할 수 있는 API를 제공한다고 합니다. 따라서 제가 원하는 작업을 수행하는 것이 이론적으로는 충분히 가능한 것이지요? 문제는 최선의 접근 방식이 무엇인지입니다.
예를 들어, Discourse가 새 사용자 가입을 관찰하고 이 검증 로직을 수행하며, 필요한 경우 정보 제공 메시지와 함께 등록을 중단할 수 있는 이벤트 리스너(또는 플러그인?)를 작성할 수 있다면 —("죄송합니다. XYZ 협회의 회원이어야 합니다"와 같은 메시지를 표시할 수 있다면) — 그것은 정말 훌륭할 것입니다.
대안으로, 제가 잘 아는 언어인 PHP로 사용자 등록 페이지를 직접 작성하여 두 API를 모두 사용할 수도 있다고 생각합니다. 하지만 그러면 Discourse 설치 환경을 어떻게 해킹해야 제 가입 페이지가 사용자를 제 커스텀 버전으로 리디렉션하게 할지 알아내야 합니다.
따라서 전체적인 전략이 어떻게 구성되어야 하는지, 그리고 이를 수행하는 방법을 배우기 위해 어디부터 살펴봐야 하는지에 대한 조언을 듣고 싶습니다.
@Jonathan5 제안해 주셔서 감사합니다. 해당 스레드를 살펴봤는데, 솔직히 악몽 같은 상황으로 보입니다. 게다가 이 협회의 회원들이 NeonCRM을 직접 사용해 무엇에든 로그인하는 것이 아니라, 오직 협회 관리자만 그렇게 합니다. 상황이 복잡합니다.
또 다른 생각이 떠올랐습니다. 저는 Discourse를 초대 전용으로 설정해 두었습니다. 이 상태를 유지하되, 로그인 페이지의 텍스트를 “초대를 요청하려면 my.example.org/discourse-invitation으로 이동해 주세요” 정도로 수정하는 건 어떨까요? 그리고 해당 URL에서는 NeonCRM API를 사용하여 잠재적 사용원의 회원 자격을 확인하고, (확인 통과 시) Discourse API를 사용해 사용자를 생성한 뒤 초대를 보내는 스크립트를 실행할 예정입니다. 제 추론은 타당하다고 생각합니다. 맞습니까?