3

config/application.rb

config.middleware.insert_before(Rack::Runtime, Rack::ReverseProxy) do
  reverse_proxy_options preserve_host: false
  reverse_proxy '/external/app', 'https://runalong.com:64167/app'
end

特定の URL が要求されたときに別のホストで実行されている別のサーバー (レール サーバーではない) に要求を転送するために、rack-reverse-proxy を使用しています。ここで、ユーザーがdeviseを使用してsigned_inであるかどうかを確認し、リクエストをプロキシサーバーに転送するだけで、それ以外の場合はユーザーをサインインページに送り返したいと思います。

4

1 に答える 1

5

更新します。一般的な考慮事項として、ターゲットサーバーが公開されていると仮定すると、中間サーバーでのみチェックするのは安全ではないため、認証戦略を考える必要があります。

基本的に、あなたの質問に対する答えは、Devise は Rails アプリケーションに独自のミドルウェアを追加しないため、ミドルウェアで Devise を使用することはできません。Warden ミドルウェアを使用できる可能性があります。

Devise は Warden の上に乗っています。Deviseは、ミドルウェア スタックの最後にミドルウェアを挿入します (omniauth ミドルウェアも挿入できます) 。 Warden::Manager

# Initialize Warden and copy its configurations.
config.app_middleware.use Warden::Manager do |config|
  Devise.warden_config = config
end

それ以外では、Devise は Rails アプリケーション レベルで動作します。つまり、sign_inコントローラーなどのヘルパーを追加します。ただし、ミドルウェアレベル自体では機能しません。

Warden 自体は「怠け者」であり、ここで説明されています

Warden は怠惰になるように設計されています。つまり、使用しない場合は何もしませんが、使用するとすぐに動作し、ラックベースのアプリケーションで認証を許可する基本的なメカニズムを提供します。

したがって、Devise が何らかの方法で Warden を操作しない限り、Warden はあまり機能しません。Warden が行うことは、他のミドルウェア (および Rails アプリケーションも同様) からアクセス可能な環境変数に自分自身を埋め込むことです。このインスタンスを使用するように工夫してください。

env['warden'] = Proxy.new(env, self)

Warden は、他のミドルウェア (またはエンドレールアプリケーション) がスローできる特別な warden 例外もリッスンします。

 result = catch(:warden) do
   @app.call(env)
 end

ミドルウェアで Warden を使用するには、(ターゲット ミドルウェアの前に) ミドルウェアに組み込む必要があります。その後、Warden を使用できるようになります (Devise ヘルパーではありません!)。

warden sourceのコメントによると、セッション構築ミドルウェアの後に (それより前に) 埋め込む必要がありますActionDispatch::Session::CookieStore。

ラック認証用のミドルウェア ミドルウェアはアップストリームにセッションがあることを要求します ミドルウェアは認証オブジェクトをラック環境ハッシュに挿入します

セッションのWardenアクセサー:

def session
  env["rack.session"] || {}
end
于 2016-07-01T11:17:48.427 に答える