여러 Discourse 인스턴스를 사용하는 WordPress Multisite

여러분 안녕하세요,

현재 환경에 또 다른 Discourse 커뮤니티를 추가하는 것에 대한 정보 및 실행 가능성을 찾고 있습니다. 현재 WordPress 멀티사이트 환경에서 하나의 Discourse 커뮤니티를 운영 중이며, Discourse 커뮤니티 전용 사이트에는 Discourse SSO를 사용하고 있지만, WordPress 로그인에는 별도의 SSO 제공자를 사용하고 있습니다.

새로운 Discourse 커뮤니티를 위해 새로운 WP 사이트를 추가하고자 하는데, 이 멀티사이트 환경 내에서 여러 Discourse 포럼을 함께 사용할 수 있는지 명확하지 않습니다(이 표현이 이해가 된다면요). SSO가 WP 네트워크 설정이므로, Discourse 인스턴스를 하나 이상 가질 수 없는 것처럼 보입니다.

이상적으로는 다음과 같은 구성이 되기를 원합니다:

  • WP 멀티사이트
  • Discourse 인스턴스 2개

(두 Discourse 인스턴스 간에 사용자는 자신이 속한 커뮤니티에만 접근할 수 있어야 합니다.)

멀티사이트 WP 환경과 단일 사이트 Discourse(그리고 그 반대)에 대한 게시글은 읽었지만, 멀티사이트 WP와 여러 Discourse 인스턴스에 대한 정보는 찾지 못했습니다.

감사합니다

WordPress 멀티사이트 설정에서 사이트들이 두 개의 Discourse 인스턴스에 대한 SSO 제공자로 기능하는 것은 불가능합니다. 그 이유는 멀티사이트 네트워크에서는 모든 사용자가 단일 데이터베이스 테이블에 저장되기 때문입니다. 여러 Discourse 사이트가 네트워크 내의 여러 사이트에 대한 SSO 제공자로 기능하도록 허용되면, WordPress에 저장된 Discourse 사용자 ID가 고유하다는 것을 보장하는 단순한 방법이 없습니다.

감사합니다. 제가 추측한 바로는 그랬던 것 같습니다. 하나의 Discourse 인스턴스가 다른 인스턴스의 SSO 제공자로 작동하도록 허용하면서, 각 커뮤니티에 대한 사용자의 적절한 접근 권한을 유지할 수 있을까요?

Discourse 인스턴스는 다른 Discourse 인스턴스의 SSO 제공자로 기능할 수 있습니다. 귀하가 고려하고 있는 설정은 WordPress를 Discourse 인스턴스 1의 SSO 제공자로 사용하는 것이리라 추정합니다. 그러면 Discourse 인스턴스 1이 Discourse 인스턴스 2의 SSO 제공자가 됩니다. 이는 가능하다고 생각하지만, Discourse 사이트를 SSO 클라이언트이자 SSO 제공자로 동시에 구성해 본 적은 없습니다.

위에서 설명한 설정을 사용하면, Discourse 인스턴스 1의 모든 사용자는 Discourse 인스턴스 2에 접근할 수 있게 됩니다. 이는 귀하가 원하는 바가 아닐 것으로 보입니다.

이 문제를 해결하기 위한 또 다른 가능한 접근 방법은 Discourse 인스턴스를 하나만 사용하고, 카테고리 그룹 권한을 사용하여 사용자가 포럼의 어떤 부분에 접근할 수 있는지를 제한하는 것입니다. SSO 페이로드에 Discourse 그룹을 전달할 수 있습니다. WordPress 사이트에서 사용자가 접근할 수 있는 사이트를 결정하는 것은 가능해야 합니다. 각 WordPress 사이트마다 Discourse 그룹을 생성한 후, wpdc_sso_params 필터를 사용하여 SSO 페이로드에 add_groups 매개변수를 추가할 수 있습니다.

현재 Discourse SSO가 SSO 제공자 역할을 하고 있습니다. (새로운) 고려 사항은 인스턴스 1을 SSO 제공자로 사용하는 것(인스턴스 1과 2 모두에 대해)이 될 것입니다.

결국, 현재와 동일한 SSO 구성을 유지하면서 Discourse 인스턴스를 하나 더 추가하되, 인스턴스 1과 인스턴스 2 사이의 접근을 제한할 수 있는 방법을 마련하는 것입니다.

@simon님 - 현재 이 기능을 구현하고 있는데, WP Discourse 플러그인에서 SSO Client 옵션이 보이지 않는 이유가 무엇인지 모르겠습니다. 아래 스크린샷을 참고해 주세요.

연결 상태가 활성으로 표시되고 있습니다(API 키 마지막 사용 기록도 이를 보여줍니다). [discourse_sso_client] 쇼트코드를 추가하면 설정 문제가 있는 것 같습니다(로케이션 응답 헤더에 SSO 페이로드 대신 [discourse_sso_client] 쇼트코드가 생성한 URL이 포함되어 있습니다).

이것은 의도된 동작입니다. SSO 클라이언트 옵션은 사이트 전체 수준으로 설정된 경우에만 멀티사이트 네트워크에서 사용할 수 있습니다. 로컬 개발 환경에서 멀티사이트 네트워크를 설정하여 설정을 다시 확인해야 합니다. 오늘 늦게 다시 알려드리겠습니다.

감사합니다. 현재 네트워크 수준에서 플러그인을 설치해 두고 SSO Client를 선택해 두었습니다.

수정: query-redirect.php의 다음 부분까지 디버깅을 진행했습니다:

if ( empty( $this->options['sso-client-enabled'] ) || 1 !== intval( $this->options['sso-client-enabled'] ) ) {
   return;
}
`

이 옵션이 제 환경에서 제대로 설정되지 않는 것 같습니다. 네트워크 수준 설정 때문인지, 아니면 다른 이유인지 확실하지 않습니다.

멀티사이트 네트워크에서 플러그인을 설정하는 방법에 대한 문서가 최신 상태가 아닙니다. WP Discourse 플러그인 설치 및 설정 가이드를 정리하고 업데이트할 좋은 기회입니다.

멀티사이트 네트워크에서 SSO 클라이언트 기능을 사용하려면 플러그인을 네트워크 수준에서 구성해야 합니다. 네트워크 대시보드에서 Discourse 링크를 클릭하여 이를 수행할 수 있습니다:

Discourse 네트워크 페이지에서 ‘멀티사이트 구성 활성화’ 옵션을 선택하세요. 그런 다음 연결 설정(Connection Settings) 섹션에 Discourse URL, API 키, 게시 사용자 이름(Publishing Username)을 입력하세요. 페이지 하단으로 스크롤하여 옵션 저장(Save Options) 버튼을 클릭하세요. 페이지 상단에 'Discourse에 연결되었습니다!'라는 메시지가 표시되어야 합니다.

멀티사이트 네트워크의 사이트에서 Discourse를 SSO 제공자로 사용하려면 Discourse 네트워크 페이지 하단으로 스크롤하여 ‘SSO 클라이언트 활성화’ 옵션을 선택하세요. 또한 SSO 비밀 키(SSO Secret Key) 설정에 키를 추가하세요. 옵션을 다시 저장하세요.

이제 Discourse 사이트로 이동하여 비밀 키를 Discourse의 sso provider secrets 사이트 설정에 복사하세요. SSO 제공자 도메인으로 * 기호를 입력하세요. 해당 설정이 저장되면 다음과 유사한 형태가 되어야 합니다:

이제 Discourse에서 enable sso provider 옵션을 선택하세요.

이러한 설정이 완료되면, 네트워크의 모든 사이트에서 WP Discourse SSO / SSO Client 탭으로 이동하면 다음과 유사한 페이지로 이동해야 합니다:

빠른 테스트를 위해 ‘로그인 링크 추가’ 및 ‘이메일로 기존 사용자 동기화’ 옵션을 선택하세요. 그런 다음 WordPress 사이트에서 로그아웃하세요. wp-login.php 페이지에 표시되는 ‘Discourse로 로그인’ 링크를 클릭하여 다시 로그인할 수 있어야 합니다.

기본 WordPress 로그인 페이지를 사용하지 않는 경우, 사이트의 게시물에 [discourse_sso_client] 쇼트코드를 복사해 넣어 보세요. 이 쇼트코드는 로그인되지 않은 사용자만 페이지에 마크업을 표시합니다. 또한 다음 형식으로 링크를 구성하여 로그인 링크를 만들 수도 있습니다:

<a href="https://example.com/?discourse_sso=1&redirect_to=https://example.comt/">Discourse로 로그인</a>

이렇게 하면 사용자가 Discourse를 통해 사이트에 로그인한 후 redirect_to 파라미터 값으로 설정한 WordPress 페이지로 리디렉션됩니다.

디버깅 결과를 바탕으로, Discourse 네트워크 페이지에서 ‘SSO 클라이언트 활성화’ 옵션이 활성화되지 않은 것으로 보입니다. 해당 옵션이 활성화되어 있는지 확인해 주시고, 여전히 문제가 발생하면 알려 주세요.

SSO 클라이언트가 작동하지 않도록 막고 있던 코드를 찾은 것은 정확하지만, 그 조건은 잘못 작성되었습니다:

if ( empty( $this->options['sso-client-enabled'] ) || 1 !== intval( $this->options['sso-client-enabled'] ) )

if ( empty( $this->options['sso-client-enabled'] ) )로 단순화되어야 합니다. 플러그인의 다른 모든 부분에서 사용되는 패턴입니다.