2

OmniAuth を使用する Rails エンジンを構築しています。OmniAuth はいくつかのミドルウェアを Rails ミドルウェア スタックに追加する必要があり、OmniAuth によると、これを行うには初期化子で行う方法が推奨されています。試してみたところ、Rails アプリの起動時に読み込まれるイニシャライザーを gem 内に作成することに成功しました。今、私は自分の宝石にいくつかの構成オプションを追加しようとしています。宝石の初期化子が機能する前に、宝石のユーザーが別の初期化子を作成して宝石を構成できるようにしたいと考えています。

私が発見したのは、すべてのエンジン内の初期化子が最初にロードされることです。次に、Rails アプリ内の初期化子が読み込まれます。読み込み順序を制御できるような方法でイニシャライザに名前を付けたいと思っていましたが、Rails アプリのイニシャライザは依然として gem のイニシャライザの後に処理されます。これは私には完全に理にかなっていますが、初期化子のロード順序の問題が残ります。Rails アプリは最後に実行されるため、gem を構成する機会が与えられるまでに、gem は既に作業を完了しています。

次に考えたのはafter_initialize、エンジンの Railtie 内でコールバックを使用することでした。ほとんどの状況ではこれでうまくいくかもしれませんが、この特定のユース ケースでは役に立ちません。が呼び出されるまでafter_initializeに、ミドルウェア スタックは凍結され、変更できなくなります (これにより、ミドルウェア スタックを変更することだけを目的とするコードでは役に立たなくなります)。

現時点では、回避策は 1 つしかありません。Rails アプリは、application.rb 内で gem を構成する必要があるため、初期化子が実行される前に gem を構成します。

誰かが私が見逃しているものを見ていますか? 初期化子が処理された後 (ただし、Rails がブート プロセスのファイナライズを開始する前) に gem が何らかの作業を行う方法はありますか? そうでない場合、イニシャライザが処理されるとすぐに発火する別のフックが Rails にあると便利なようです。

4

1 に答える 1

3

@Raffael が提案したリンクのおかげで、回避策を思いつくことができました。他の誰かが同様の状況に遭遇した場合に備えて、その日をapp_middleware救った.

次の方法で app_middleware を使用して OmniAuth ミドルウェアを登録できました。

class Railtie < Rails::Railtie
  config.before_initialize do
    setup_proc = lambda do |env|
       options = {
        issuer: "foo",
        # Other options ...
      }
      env['omniauth.strategy'].options.merge!(options)
    end

    config.app_middleware.use OmniAuth::Builder do
      provider :saml, :setup => setup_proc
    end
  end
end

これは、私が打っていた初期化順序を解決するのに役立ちました。

于 2015-12-28T20:13:29.813 に答える