異なるオリジンのカスタム Discourse フロントエンドアプリでの MessageBus の使用

開発
1

もし同じことを試行している方がいて、少しのガイダンスを必要としている場合に備えて、ここに記録しておきたかったのです。

現在、React フロントエンドと Discourse バックエンド、および一部の Discourse 機能をカスタマイズするプラグインを組み合わせて作業しています。カスタムフロントエンドアプリで MessageBus を動作させたいと考えていましたが、フロントエンドが Discourse とは異なるオリジンから提供されているため、CORS の問題に直面しました。

Discourse が MessageBus 環境に対して Access-Control-Allow-Origin ヘッダーを Discourse.base_url_no_prefix に設定していることに気づきました。これは、MessageBus が Discourse のデフォルトの Ember フロントエンドと連携することが自然に想定されているためです。

MessageBus の GitHub リードミー に記載されている通り、MessageBus 環境に追加のヘッダーを追加することが可能です。これはまさに Discourse の MessageBus イニシャライザーが行っていることであり、Access-Control-Allow-Origin が Discourse.base_url_no_prefix に設定される箇所です。

それをカスタマイズするために、私のプラグインに以下のコードを追加しました。

  MessageBus.extra_response_headers_lookup do |env|
    env["__mb"][:extra_headers].merge({
      "Access-Control-Allow-Origin" => "http://your-custom-domain.com"
    })
  end

これにより、Discourse のイニシャライザーで setup_message_bus_env を呼び出して確立される MessageBus 環境を決定する際の重要な Discourse のロジックを上書きすることなく、カスタム値を許可するという利点があります。

この設定は、ここにいる多くの開発者にとって非常に自明なものかもしれませんが、要素を組み合わせることが常に容易ではないため、記録する価値があると思いました。もしこれで誰か一人でも一時間の試行錯誤を節約できれば、それは素晴らしいことです！

もちろん、上記の内容に誤りや不正確な点があれば、お知らせください。編集いたします！

「いいね！」 10