멀티사이트(Multisite) + SSO 구조의 사이트를 구축하거나 발견하신 분이 계신가요? 참고할 수 있는 사례가 궁금합니다!
이상적으로는 멀티사이트를 여러 도시별로 운영하여, 각 도시의 로컬 뉴스와 행사에 집중할 수 있으면 좋겠습니다. 또한 인터넷을 활용해 함께 일하는 사용자들 간의 협업을 위해, 도시를 넘나드는 주제에 대한 토론도 가능해야 합니다.
미리 감사드립니다.
로컬 콘텐츠 사이트를 준비 중인 클라이언트를 위해 작업하고 있습니다. 여러 사이트를 만들 계획은 없으며, 대신 Discourse 카테고리를 활용해 도시/지역별로 콘텐츠를 구분할 예정입니다. 신규 사이트의 가장 큰 문제 중 하나는 임계 질량(critical mass)을 확보하는 것입니다. 처음부터 사이트를 여러 개로 나누면 개별 사이트가 성공할 확률이 크게 떨어집니다. 모든 사용자를 위한 단일 사이트를 만들고, Discourse가 제공하는 도구를 활용해 콘텐츠를 정리하는 것이 더 좋습니다.
사이트가 성공적으로 운영된다면, 서브사이트로 분리하는 것이 합리적일 수 있습니다. (아마 그렇게 되지는 않겠지만,谁知道呢?) 한 Discourse 인스턴스에서 카테고리를 다른 인스턴스로 이동하는 것은 그렇게 어렵지 않습니다. 따라서 결국 필요하지 않을 수도 있는 여러 사이트로 시작할 필요가 없습니다.
어떤 사용자가 하나의 “메인” Discourse 사이트를 모든 사이트의 인증 소스로 사용하여 수천 개의 멀티사이트를 운영하기를 원한다는 요청을 받고 이에 대해 생각해 보았습니다.
일정량의 작업이 필요하지만, 수동으로 설정할 수 있는 사이트 수를 초과하지 않는다면 훨씬 적은 작업으로 가능합니다.
여러 사이트에 동일한 데이터를 유지하는 것은 복잡합니다(ActivityPub 플러그인을 사용하여 이를 수행하는 방법에 대한 논의가 있었습니다) 하지만, 모든 사람이 관심을 가지는 내용은 메인 사이트에 호스팅할 수 있습니다.
SSO를 위해 DiscourseConnect를 사용하시려는 건가요? 예를 들어, 하나의 ID 제공자 사이트에서 DiscourseConnect를 사용하여 여러 Discourse 사이트의 사용자를 인증하는 방식처럼요? 그렇다면 기술적으로 가능하다고 생각하지만, 이는 DiscourseConnect의 의도된 사용 사례는 아닙니다. 도전 과제는 SSO 요청이 어느 Discourse 사이트에서 시작되었는지를 파악하는 것입니다. 각 Discourse 사이트의 discourse connect url 설정에 URL 매개변수를 추가하여 이 문제를 해결할 수 있다고 _생각_합니다. 예를 들어:
https://example.com/sso?subdomain=foohttps://example.com/sso?subdomain=bar
이 경우 ID 제공자 사이트의 코드는 SSO 요청을 적절한 서브도메인(foo.example.com 또는 bar.example.com)으로 리디렉션할 수 있습니다.
과거에 이와 유사한 것을 구현한 사이트를 알고 있지만, 그들이 현재도 해당 방식을 사용하고 있는지는 확실하지 않습니다.