Discourse 用の Ghost サインイン プラグインを作成することは可能ですか？

開発
1

1年半前にGhost連携Discourseが発表され、Ghostのメンバーは発行元と同じ権限でサイトのフォーラムにシームレスにアクセスできるようになりました。この連携の「欠点」の1つは、VPSへのインストールが必要なことで、これはGhostやDiscourseの多くのユーザーにとって少し daunting（気が遠くなるような）作業だと感じるかもしれません（過去数日間、Ghostのフォーラムで議論されているように）。

ここDiscourseのフォーラムでは、数日前に2つのプラットフォームの連携について次のように述べられました。

これは素晴らしいことですが、別の選択肢として、Cloudflare Workersでセットアップできる「すぐに使える」バージョンの作成が考えられます。これにより、初心者にとっての摩擦が軽減されるかもしれませんが、さらに良い選択肢は、Discourseプラグインの作成かもしれません。そのようなことが可能であると仮定します。Sign in with Appleプラグインがすでに存在することを見ると、Sign in with Ghostプラグインも技術的に可能かもしれないことを示唆しているのでしょうか？

「いいね！」 5
2

はい、可能です。Ghost を ID プロバイダーとして設定するためのドキュメントはありますか？もしあれば、oAuth がサポートされている場合、専用のプラグインを必要とせずに既存のツールを使用してセットアップできる可能性が高いです。

「いいね！」 4
3

「いいえ、GhostはIDP（Identity Provider）として設計されているわけではありません」と言われました。そうである場合、プラグインで新しいエンドポイントを追加することは可能ですか？そうすれば、そのルートが可能になりますか？

編集：
プラグインでグループを定義することは可能ですか？そうすれば、（GhostがWebhookを送信すると仮定して）ユーザーのサブスクリプションが変更されたときにグループを同期できますか？

「いいね！」 2
4

したがって、現在のDiscourse-on-Ghost統合は、GhostではなくD-o-G機能のみをセルフホストする必要があるということになります。その統合はDiscourseConnectを使用しているため、ホスト方法に関係なく、あらゆるDiscourseのインストールでそのまま機能します。

それにはDiscourseのセルフホストが必要になります。では、それはどのような問題を解決するのでしょうか？負担は、比較的単純なGhostアドオンのセルフホストから、Discourseのセルフホストへと移行することになります。

「いいね！」 4
5

しまった、非公式・カスタムプラグインがエンタープライズプラン限定だとは気づきませんでした。あなたが「負担は、比較的シンプルなGhostアドオンのセルフホスティングから、Discourseのセルフホスティングへと移行することになります」と言った意味が分かりました。問題は、テクノロジーに疎い人にとって「シンプルなアドオン」のセルフホスティングは面倒すぎるかもしれませんが、何も自分たちの手に負えず、すべてがより有能な人の手に安全に委ねられているという安心感を求める人もいるということです。

@pmusaraj、カスタムプラグインはエンタープライズプランでしか利用できないことを考えると、プラグインに関しては「極端」な選択肢しかない、つまりセルフホスティングかエンタープライズかのどちらかということになりますか？Discourseが存続するためには収益が必要であるため、カスタムプラグインがStarterプランで利用できない理由は完全に理解できますが、ここには何か中間的な解決策があるのでしょうか？あるいは、「GhostをIDプロバイダーとして設定する」以外の方法で、まだ対処されていないルートはありますか？

「いいね！」 2
6

現実的かどうかはわかりませんが、GhostプラットフォームはホストされているサイトでDiscourseConnectを実装できる可能性があります。

別の選択肢としては、公式のDiscourse Ghostプラグインを作成し、ホストされているDiscourseサイトで利用可能なプラグインに追加することです。

どちらの場合も、Discourse/Ghost統合に対するかなりの需要があるかどうかに依存するでしょう。

「いいね！」 1
7

もし、公式および非公式のプラグインの両方を、手頃な価格のホストプランで提供するcompany 咳 があればよかったのにと思います :wink:

しかし真面目な話、そのようなソリューションは広く利用可能であるべきで、特定のサービスに依存すべきではないと思います。

D-o-GはGhostに対してJWT統合を使用しているようです。DiscourseにはJWTプラグインがあります（公式ですがエンタープライズプランのみ？）。これは調査する価値のある方向性かもしれません。

「いいね！」 2
8

Ghostについては詳しくないので、適切なアドバイスはできませんが、これだけは言えます。

  • 私たちが推奨するアプローチは、認証に既存の標準を使用することです。なぜなら、アカウントやログインに関してはセキュリティが非常に重要だからです。例えば、GitHub - discourse/discourse-oauth2-basic: A basic OAuth2 plugin for use with Discourse や Discourse OpenID Connect (OIDC) があり、これらは公式ホスティングのビジネスティアで利用可能です。あるいは、エンタープライズ向けにはSAMLがあります。
  • 上記のプラグインを考慮すると、Discourse用の特定のGhost認証プラグインは必要ないと思います。Ghostがこれらの標準のいずれかをサポートする必要があり、サポートされれば、特定のGhostプラグインは不要になります。この件については協力する用意がありますが、Ghost側がIDP機能を追加するという重い作業を行う必要があるというのが私の直感です。
  • JWTルートも選択肢の一つです。@RGJが指摘したように、プラグインが存在しますし、D-o-G仲介と同じことを行うように設定できる可能性があります。ただし、これはやや時代遅れの標準であり、一般的にはOAuth、OpenID、SAML、またはDiscourseConnectを推奨しています。
「いいね！」 4
9

こんにちは、私はここに新しく、Ghost-Discourse SSO統合に関するすべてのスレッドを読んでいます。私はホストされたGhost(Pro)プランを利用しており、ユーザー認証の信頼できる情報源としてGhostを使用して、SSOを備えたホストされたDiscourseインスタンスをセットアップしたいと考えています。現在、SSOミドルウェアアプリを自己ホストして自分でセットアップすることしか選択肢がないと理解していますが、それは正しいですか？

10

まず、GhostがOAuth経由でIDプロバイダーとして機能することをサポートしているかどうかをGhostに問い合わせるべきです。フォーラムをざっと検索しただけでは、それがサポートされているかどうかはよくわかりません。こちらの投稿は2024年4月のものですが、OAuthについて言及されていますが、Ghostがログインプロバイダーとして機能するためのものなのか（Ghostが別のものをログインプロバイダーとして使用するためのものなのか）はわかりません。

「いいね！」 2
11

それが私の最初の動きでした。Ghost Supportは私の機能リクエストを登録しましたが、基本的にそれはすぐに、あるいは決して起こらないだろうと言いました。息を止めて待つ代わりに、エンジニアを雇ってDropletにDoGをインストールしました。それは完璧に動作しているので、これが効果的な回避策であると保証できます。Ghost Supportがこの問題に対してなぜこれほど頑ななのか理解できません。

「いいね！」 1