問題タブ [rack-middleware]

config/application.rb

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

バックグラウンド

私のアプリケーションでは、さまざまな目的で 2 つの異なる Facebook アプリに接続する必要があり、そのために以下に示すコードを使用しています。

問題

以下に示すメソッドのようにカスタムcallback_pathfacebook_opts_for_social_sharingを使用すると、コールバック ハンドラ、つまりExternalApiAuthController#create_social_sharing_auth_accountアクションrequest.env['omniauth.auth']で nil が返されます。同様の問題がintridea/omniauthリポジトリで報告されています。

/config/routes.rb

/app/controllers/external_api_auth_controller.rb

/config/initializers/omniauth.rb

そのコードで起こっていることは、Request Phasecallback_pathの間に正しくピックアップされていることです。ただし、リクエスト フェーズが終了し、OmniAuth::Strategies::OAuth2#request_phase がリダイレクトを開始するとすぐに、OmniAuth::Strategies::Facebook.default オプションのみがOmniAuth::Strategyインスタンス によって使用されます。これらのオプションには(リダイレクトが開始された後)が含まれていないため、次の行を評価する と常に false が返されるため、コールバック フェーズが実行される機会がありません。callback_pathon_callback_path?return callback_call if on_callback_path?

アプローチ1

この制限を回避するために、OmniAuth::Strategies::Facebook.default オプションを送信して、各フェーズで取得されるようにする方法を試しcallback_pathました 。したがって、 method のように SETUP_PROC のコードを介して渡すのではなく、次の方法で渡しました。つまり、メソッド呼び出しfacebook_opts_for_social_sharingのオプションとして渡しました。OmniAuth::Builder#provider

Rails.application.config.middleware.use OmniAuth::Builder do provider :facebook, setup: SETUP_PROC, callback_path: ExternalApiAuthUrl.sharing_auth_callback_path(provider: provider_facebook) end

そして、それを機能させるために、SETUP_PROCを次のように更新しました

ただし、これによりカスタム callback_pathシナリオは機能しますが、カスタム callback_path を含むオプションはOmniAuth::Strategyインスタンスで常に使用できるため、デフォルトの callback_path /auth/facebook/callbackシナリオは失敗します。callback_path

アプローチ 2

したがって、アプローチ 1によってもたらされる制限を回避するために、リクエストの path_info と params に基づいて、必要なオプションで戦略ミドルウェアを呼び出すミドルウェアを使用する別のアプローチを試しました。

/app/middleware/omniauth_builder_setup.rb

/config/application.rb

/config/initializers/omniauth.rb (コメントアウトuse OmniAuth::Builder)

このミドルウェア アプローチでは、デフォルトの callback_path/auth/facebook/callbackとカスタムの callback_pathを使用する場合など、両方のシナリオでコールバック フェーズが開始されます/auth/facebook/social_sharing/callback。しかし、コールバック段階では、次のエラーで失敗します:

OmniAuth::Strategyにいくつかのログ ステートメントを追加したところ 、次のログが生成されました。

ミドルウェアのコールバック フェーズ中に @app がOmniAuth::Strategies::Facebook のインスタンスを保持していることに気付いた場合、コントロールが OmniAuth::Strategy に到達するとすぐに、OmniAuth::Strategy インスタンス内の @app が class を参照しますOmniAuth::Strategies::Facebook。

ミドルウェアに問題があると確信しています。以前にミドルウェアを使用したことがないため、この @app の概念を理解していません。それを把握するためにウェブ上のいくつかのリソースを参照しようとしましたが、成功しませんでした.

1. 希望どおりに動作するようにミドルウェアを修正するのを手伝ってくれる人はいますか?

2. 可能であれば、@app の概念と、@app.call(env) が返す必要があるステータス、ヘッダー、および本文の値を理解できるようにしてください。そうでない場合は、干渉せずにスキップして先に進む必要があります。この動作を達成する方法がわかりません。

PS 過去 2 日間からこの制限を回避するのに苦労しています。ここに記載されているすべての詳細、調査結果、アプローチを使用して、コミュニティの誰かが私の問題を解決するために私を導いてくれることを願っています。

ありがとう。

サイトを翻訳する必要があり、この目的のために I18n を使用しています。ロケールを URL パラメータとして使用して、Cookie に保存されているロケールにユーザーをリダイレクトしたいと考えています。
これは、リダイレクトに使用しているroutes.rbの文字列です。

問題は routes.rb ファイルにあります: I18.locale は常にデフォルトのロケールに設定されているため、ユーザーのロケールへのリダイレクトはなく、デフォルトのロケールへのリダイレクトがあります。

また、ミドルウェアをデバッグしましたが、ご覧のとおり、I18n.locale が正常に設定されています。

routes.rb で I18n.locale を設定する方法はありますか?

Rails アプリで使用するラック ミドルウェアを作成しています。基本的に、特定の URL に一致するリクエストをデータベースに記録する必要があります。これを行うには、データベース構成をミドルウェアに渡して、DB との接続を確立できるようにする必要があります。私はやろうとしています:-

しかし、これはエラーを出しています

config/application.rb:40:in <class:Application>': undefined methodread' for # (NoMethodError)

byebug を追加して byebug コンソールで実行すると、正常に動作します。理由がわかりません。私は次のことをしたい： -

1. ミドルウェアに引数として渡す前に、データベース構成を読み取って変更する必要があります。
2. リクエストURLのドメインを読みたい。Apartment gemを使用しており、スキーマ名はドメイン名になります。

こことここで複数の記事をフォローしました。私はRailsの初心者で、良いリソースを知らないので、助けてください。前もって感謝します！

認証には Devise を使用し、SAAS アプリでのマルチテナンシー サポートには Apartment を使用します。

ログインに失敗すると、devise はログイン ページ (Users::SessionsController#new) に「リダイレクト」し、Apartment::Tenant.current以前にミドルウェアで設定されたTenantElevator値はデフォルト値の「public」に戻ります。

これは、Devise が実際にログイン ページにリダイレクトするのではなく、新しいラック環境で FailureApp (ログイン ページをレンダリングする) を呼び出し、その応答を返すために発生しています。新しいラック アプリにはTenantElevatorミドルウェアがないため、テナントはラック アプリ内に設定されません。

誰でもこれを修正する方法を知っていますか? TenantElevator ミドルウェアを Failure アプリに追加する方法はありますか?

ログインに失敗した後、Devise は新しいラック環境で失敗したアプリを呼び出し、通常はログイン ページである応答を返しているようです。

ミドルウェアを追加して障害アプリを作成するにはどうすればよいですか?

Rack-timeout gem をインストールし、イニシャライザ内に rack_timeout.rb を作成しました。rack_timeout.rb 内で Rack::Timeout.service_timeout = 1 を設定しました。コントローラでタイムアウトを超えた場合に実行を停止するために、rack-timeout を制限したいAPI内のコントローラーよりも.APIコントローラーの実行のみを停止する必要があります.lib内にmy_middleware.rbという名前のカスタムミドルウェアを作成しました

config/development.rb

しかし、それは機能していません。タイムアウトが発生したときに、どこでもラックタイムアウトが例外をスローしています。