멀티사이트(Multisite) + SSO 구조의 사이트를 구축하거나 발견하신 분이 계신가요? 참고할 수 있는 사례가 궁금합니다!
이상적으로는 멀티사이트를 여러 도시별로 운영하여, 각 도시의 로컬 뉴스와 행사에 집중할 수 있으면 좋겠습니다. 또한 인터넷을 활용해 함께 일하는 사용자들 간의 협업을 위해, 도시를 넘나드는 주제에 대한 토론도 가능해야 합니다.
미리 감사드립니다.
멀티사이트(Multisite) + SSO 구조의 사이트를 구축하거나 발견하신 분이 계신가요? 참고할 수 있는 사례가 궁금합니다!
이상적으로는 멀티사이트를 여러 도시별로 운영하여, 각 도시의 로컬 뉴스와 행사에 집중할 수 있으면 좋겠습니다. 또한 인터넷을 활용해 함께 일하는 사용자들 간의 협업을 위해, 도시를 넘나드는 주제에 대한 토론도 가능해야 합니다.
미리 감사드립니다.
I’m working with a client that’s starting a site for local content. We’re not planning multiple sites, but rather using Discourse categories for different cities/regions. A huge problem for new sites is getting critical mass. If you start by dividing into different sites, the odds that any one will succeed drops massively. Better to have one site for everyone and use the tools DIscourse provides to organize content.
If the site is successful, it might make sense to split up into subsites. (Probably won’t happen, but who knows?) Moving categories from one Discourse instance to another isn’t hard. So you don’t need to start off with multiple sites that you might not ever need.
I started doing some thinking for someone who wanted to have thousands of multisite sites with a single “main” Discourse site as the authentication source for all of them.
It seemed possible, with some work (and much less work if you have no more sites than you’re willing to configure by hand).
Having the same data on multiple sites is complicated (there has been some discussion about doing this with the ActivityPub Plugin), but you could host the everyone-cares stuff on the main site.
Are you wanting to use DiscourseConnect for SSO? For example, from one identity provider site, authenticate users on multiple Discourse sites with DiscourseConnect? If so, I think it’s technically possible to do this but it’s not the intended use case for DiscourseConnect. The challenge will be to determine which Discourse site an SSO request has originated from. I think this can be done by adding a URL parameter to each Discourse site’s discourse connect url setting. For example:
https://example.com/sso?subdomain=foohttps://example.com/sso?subdomain=barThe code on the identity provider site could then redirect SSO requests to the appropriate subdomains: foo.example.com or bar.example.com.
I’m aware of a site that implemented something like this in the past, but I’m not sure if they’re still using that approach.