그 CSS 페이지를 수백 번이나 방문했는데, 임베딩용 CSS가 있다는 걸 한 번도 눈치채지 못했다…

그 CSS 페이지를 수백 번이나 방문했는데, 임베딩용 CSS가 있다는 걸 한 번도 눈치채지 못했다…

오늘 이 기능을 구현하려고 했는데 몇 가지 문제가 있습니다:
가장 놀라운 점은 임베드가 포함된 URL을 방문할 때마다 새로운 토픽이 생성된다는 사실이었습니다. 이는 OP(최초 게시물)에 나와 있습니다:
제가 생각할 수 있는 유일한 해결책은 다소 해킹적인 방식이며, 임베드 엔드포인트를 핑(Ping)하기 위해 단기 SSR/캐싱에 의존하는 것입니다:
따라서 로직은 다음과 같을 것 같습니다:
$discourse/embed/info?embed_url=$link를 확인합니다.
토픽이 존재하면 임베드를 평소처럼 표시합니다.
존재하지 않으면 $discourse/new-topic?subject=$link로 연결되는 “대화 시작” 버튼을 표시합니다.
이 방식이 작동할까요, 아니면 추가로 처리해야 하는 다른 링크가 있을까요?
임베드가 포함된 페이지를 처음 방문할 때만 새로운 토픽이 생성됩니다. 이후 방문 시에는 해당 URL과 연결된 기존 토픽이 렌더링됩니다.
자동 토픽 생성을 원하지 않는 경우, API 호출을 통해 가장 적합한 방식으로 토픽을 생성한 뒤 topicID를 임베드에 전달하여 연결을 수동으로 제어할 수 있습니다.
알겠습니다. 제 경우에는 수십만 개의 페이지가 있으므로 이것이 매우 큰 문제입니다.
이렇게 하는 건가요?
…이 방식에도 문제가 있습니다. 예를 들어, 후속 참여 없이 버튼만 클릭되는 경우가 발생할 수 있죠.
사용자가 실제로 댓글을 남긴 경우에만 토픽을 생성할 수 있는 방법이 있을까요? 다음과 같은 형태처럼요:
$discourse/new-topic?subject=$link.
아니면, 여기서의 문제가 결정적인 결합을 위해 topicID를 전달할 수 없다는 점인가요?
아니요, Discourse에서는 존재하지 않는 주제에 답글을 남길 수 없습니다.
이러한 요구 사항을 해결하기 위해, 모든 임베드 주제를 비공개(unlisted) 주제로 생성할 수 있도록 했습니다. 누군가 처음 답글을 남기면 자동으로 목록에 표시됩니다.
토픽 생성은 서버에서 실행되는 인증된 요청이 필요할 것 같습니다. 이를 처리하고 싶지 않다면, UI에 버튼을 추가하여 아래와 유사한 코드를 트리거하는 다른 접근 방식도 가능합니다(이 코드는 원래 페이지의 head 태그에 자동으로 추가될 코드입니다): discourse/public/javascripts/embed.js at 581dbca97f2b55c9bbbe40dc3b58a9df7409d77f · discourse/discourse · GitHub. 이 데이터 using 이 iframe 요소를 생성하는 것입니다:
<div id='discourse-comments'></div>
<meta name='discourse-username' content='DISCOURSE_USERNAME'>
<script type="text/javascript">
DiscourseEmbed = {
discourseUrl: 'http://127.0.0.1:4200/',
discourseEmbedUrl: 'EMBED_URL',
// className: 'CLASS_NAME',
};
</script>
수정: 직접 시도해 보았습니다. 이것은 개념 증명(PoC)일 뿐입니다: discourse-embed-iframe-test/app/routes/triggering-embed-code.tsx at main · scossar/discourse-embed-iframe-test · GitHub. 이것이 당신의 문제에 대한 훌륭한 해결책이라고 생각하지는 않습니다.
논리는 전적으로 클라이언트에 있습니다(로더 함수는 편의를 위해 존재합니다). 불행히도 클라이언트가 Discourse에서 토픽이 존재하는지 알 수 있는 좋은 방법이 없습니다. 따라서 토픽이 이미 존재하는지 여부에 따라 UI를 커스터마이징하는 것은 불가능합니다. 이를 해결할 방법은 있지만, 아마도 앱의 데이터베이스에 무언가를 작성해야 할 것입니다.
Discourse는 iframe에서 부모 문서로 데이터를 전달하기 위해 Window: postMessage()를 사용합니다. 예를 들어, 임베드된 댓글에서 답변 링크가 클릭될 때: discourse/app/assets/javascripts/discourse/scripts/embed-application.js at 581dbca97f2b55c9bbbe40dc3b58a9df7409d77f · discourse/discourse · GitHub. 토픽이 생성되었음을 나타내는 메시지를 부모 문서로 보낼 수 있을지 궁금합니다. 그러면 사이트가 커스텀 로딩 스피너를 설정하거나, 토픽이 댓글을 받을 준비가 되었는지 여부에 따라 다른 UI를 표시하는 등의 작업을 수행할 수 있게 됩니다.
새로운 게시물에 기본 링크(primary link)를 할당할 수 있다면 그렇게 될 필요가 없을 것 같습니다:
$discourse/new-topic-link?link=$link
이는 이미 존재하는 스레드로 포워딩하고, 그렇지 않으면 임베드 관리(admin)의 기존 로직을 사용할 것으로 예상됩니다. 아마도 템플릿을 사용할 수도 있겠죠?
이 문제를 해결하는 또 다른 방법은 해당 링크를 참조하는 모든 게시물을 검색하여 일치하는 항목을 사이트 전체 대화의 일부로 표시하고, SSR을 통해 페이지에 직접 렌더링하는 것입니다. 임베드가 기본적으로 보기 전용(view only)이므로 이는 동등한 해결책이 될 수 있습니다. 여기서 가장 명백한 문제는 사용자가 참여하기를 원할 때 어떤 스레드로 사용자를 보내야 하는지를 선택하는 것입니다.
수정: 링크 내용으로 게시물을 검색하는 방법을 알아낼 수만 있다면
이 기능이 Discourse 포럼을 공격하는 데 사용될 수 있을지 궁금합니다. 구체적으로, 누군가가 한 호스트의 여러 URL에서 방문된 페이지를 위조하여 수많은 주제를 생성할 수 있는 것일까요?
Discourse 커뮤니티 여러분, 안녕하세요!
Docusaurus v3를 사용하면서 사이트에 Discourse 댓글을 통합하고 싶은 분들을 위해 제가 개발한 플러그인을 소개하게 되어 기쁩니다.
이 플러그인은 Docusaurus v3 사이트에 Discourse 댓글을 쉽게 통합할 수 있도록 도와줍니다. 주요 기능은 다음과 같습니다:
Docusaurus v3를 사용 중이며 문서나 블로그 게시물에 Discourse 댓글을 추가하고 싶다면, 이 플러그인이 해당 과정을 크게 간소화해 줍니다.
플러그인은 npm에서 찾을 수 있습니다: docusaurus-plugin-discourse-comments
예를 들어 단일 임베드 가능 호스트 blog.example.com과 와일드카드 경로 허용 목록 /.*가 있다고 가정해 보겠습니다.
같은 호스트를 사용하여 추가 임베드를 추가하고 싶지만, 이번에는 /new-release.*와 같은 다른 허용 목록과, 예를 들어 releases라는 추가 태그를 함께 사용하고 싶습니다.
명백하게 “새 릴리스” 토픽은 두 호스트/경로 조합 모두와 일치할 수 있는데, 이 중 어느 쪽이 우선순위를 갖게 됩니까? 규칙은 어떤 순서로 평가됩니까?
비공개 포럼의 주제를 다른 호스트에 임베드할 수 없다는 점이 여전히 유효한가요? 저희는 제품을 호스팅하기 위해 Kajabi를 사용하고, 독립 웹사이트에서 Discourse를 댓글 플랫폼으로 활용하고 있습니다. 각각 별도의 로그인이 필요하므로, 여전히 "불가능"할 것으로 예상됩니다. 하지만 이는 저희 사용자에게 큰 제한 요소이며, 전용 토론 공간이 있는 모듈이 750개 이상이라 상당한 불편을 주고 있습니다. 만약 각 Kajabi 모듈의 Discourse 주제를 같은 페이지에 임베드할 수 있다면, 해당 페이지에서 댓글을 달 수 없더라도 모든 것이 훨씬 간소화되고 Discourse의 관련 주제로 쉽게 링크할 수 있을 것입니다.
그래서, 이 부분에 대한 진행 상황은 어떻게 되나요? 아니면 비공개 포럼의 영구적인 한계로 남게 될까요?
비공개 포럼(별도 도메인을 사용하는 사이트)의 코멘트를 임베드할 수 없다는 것을 확인했습니다:
그러나 제 동료는 Ghost 사이트의 코멘트로 완전히 다른 도메인의 공개 포럼을 사용하고 있으며, 대부분 무료 게시물을 게시하고 있습니다. 그는 최근에 첫 번째 멤버 전용 게시물을 게시했고, 저는 해당 Discourse 주제를 “Everyone”(모든 사용자)이 볼 수 있는 범주가 아니라 Ghost 사이트의 유료 멤버와 연결된 특정 그룹만 볼 수 있는 범주로 변경했습니다. 그 결과 임베드에는 “Error Embedding”(임베드 오류) 메시지가 표시됩니다.
OP(원문 작성자)는 별도 도메인의 비공개 포럼은 임베드가 작동하지 않는다고 말했지만, 제 경우처럼 공개 포럼인데 비공개 범주가 있는 상황입니다. 제가 겪고 있는 문제는 공개 포럼의 비공개 범구가 기능적으로 비공개 포럼과 동일한가 때문에 발생하는 것일까요? 저는 다음 코멘트를 읽었고, 이는 이러한 주장을 뒷받침하는 것 같습니다:
공개 포럼의 비공개 범주에 있는 주제를 기본적으로 임베드할 수 없는 것이 사실이라면, 임베드(및/또는 플랫폼)를 조정하여 이를 해결할 방법이 있을까요? Discourse가 비공개 Ghost 게시물을 크롤링할 수 없어 비유료 사용자에게 게시물의 내용이 의도치 않게 노출되는 것을 피하기 위해, 비공개 범주를 일시적으로 공개로 설정하는 것은 괜찮으므로 이 문제를 (기대되는) "수정"을 서두를 필요는 없습니다. 하지만 이 문제를 해결할 수 있다면 나중에 임베드를 수정하거나 플랫폼에 PR을 제출해 줄 사람을 고용하는 것도 마다하지 않을 것입니다.
안녕하세요, 저는 Ghost 블로그에서 임베드 기능을 사용 중인데, 포럼에 블로그 게시물이 어떻게 표시되는지와 관련하여 몇 가지 문제를 겪고 있습니다. 아래는 현재 설정된 호스트입니다:
서브도메인 설정에 어려움이 있었기 때문에(도메인은 Discourse 포럼이 호스팅된 곳과 다른 ISP를 사용하고 있습니다) 태그(Tags) 방식을 선택했습니다.
그러나 발생하는 문제는 모든 블로그 게시물이 제 Discourse 포럼의 ‘Blog’ 카테고리에만 표시된다는 것입니다. Discourse의 게시물 작성자로 관리자 계정을 사용하고 있으며, 세 가지 카테고리 모두에서 관리자가 새 주제를 생성할 수 있도록 설정되어 있습니다.
이 문제를 일으키는 원인에 대해 어떤 통찰을 주실 수 있을까요?
각 경로를 명시하는 건 어떨까요? 예를 들어, 블로그 카테고리로 가도록 예정된 포스트가 /blog/ 아래에 있다면, 기억이 맞다면 /blog/*를 사용할 수 있습니다.
그것은 Ghost 블로그에서는 작동하지 않습니다 (적어도 상당히 표준적인 설치 환경에서는요). 저는 메인 도메인(alphagamer.net)을 사용하고 있으며, Ghost 블로그는 기본적으로 도메인 뒤에 블로그 게시물 제목을 기반으로 경로를 자동으로 추가합니다. 경로를 직접 추가해 보았지만, 그냥 삭제만 됩니다.
디스코urse 댓글(토픽)을 디스코urse 주제에 임베드할 수 있을지 궁금합니다. 사이트의 나머지 부분(헤더나 푸터 제외)은 제외하고, 답글 버튼만 포함하는 iframe을 사용하는 방식이 가능할 것 같습니다.
댓글 섹션이 있는 기사와 유사한 형태라고 보시면 됩니다. 만약 이 방식이 기사 블로그의 마지막 페이지에 임베드된 댓글 토픽의 투표 기능과 결합된다면 더욱 좋을 것 같습니다.
Ghost와 함께 사용해 봤는데, SSO 통합이 없다는 점 때문에 사용자들이 불만을 제기하는 것 외에는 문제가 없었습니다.
예제 코드를 조금 수정해야 했던 기억이 나네요.
임베드가 하나뿐이라면 잘 작동하는 것 같습니다. 하지만 다른 디스커스(Discourse) 카테고리에서 서로 다른 유형의 블로그 포스트를 임베드하려면 약간의 추가 조정이 필요할 것 같습니다.
태그를 사용하면 작동할 줄 알았는데, 태그만으로는 제 환경에서 원하는 결과를 내지 못하는 것 같습니다. Ghost에서는 기본적으로 폴더 구조(예: alphagamer.net/blog/ 및 제가 필요한 다른 경로)를 추가할 수 있는 콘텐츠 컬렉션을 만들어야 할 것 같습니다. 이번 주말에 이 방법을 시도해 보고 "경로 허용 목록"을 업데이트한 뒤, 작동하게 되면 여기서 결과를 공유하겠습니다.
허용 목록을 다음과 같이 쉼표로 구분할 수 있을까요?
/blog/.*,/articles/.*
수정: 그렇게 하면 작동하지 않는 것 같습니다. 이것도 작동하지 않습니다:
/(blog|articles)/.*
아마도 두 개의 별도 호스트로 지정해야 하는 것 같습니다.