プロキシ経由の OmniAuth ログインを追跡する

ユーザーが「サインイン」をクリックすると、プロバイダーのページに到達し、Rails に戻ります。次の手順は、Rails サーバーから新しい接続を開始するため、それでも失敗することがあります。

browser → provider authorization page → browser callback to Rails
Rails   → provider token endpoint → Rails

ブラウザは自身のネットワーク設定で認可リダイレクトをたどります。Rails は、導入済みの OmniAuth ストラテジーが選ぶ HTTP クライアントを使ってバックチャネルのトークン交換を行います。企業プロキシの背後で動くワーカーは、プロバイダーへのリクエストにこの経路が必要です。

OAuth 1.0 にも、ユーザーがアクセスを認可する前にサーバー側でリクエストトークンを取得する手順があります。OAuth 2.0 の認可コードフローには、コールバック後に独自のトークン交換があります。正確な順序はストラテジーによりますが、ブラウザとアプリケーションサーバーは別々の出発点のままです。

クライアントの設定を特定する

ストラテジーをたどり、そのトークンとプロバイダー API リクエストを送る HTTP クライアントまで進みます。そのクライアントの文書化されたプロキシオプションを使います。クライアントオプションを OAuth ライブラリに渡すストラテジーもあれば、その下の HTTP 接続を設定するものもあります。あるストラテジーが受け付けるオプションが、自動的に OmniAuth 共通のオプションになるわけではありません。

プロバイダーの認可・トークン・コールバック URL は、実際のサービスを指すままにしておきます。外向きプロキシはプロバイダーに到達するためのトランスポート設定であり、コールバックアドレスの代替でも、OAuth リクエストのパラメーターに加える項目でもありません。

ログインを追跡するときは、最後に完了した手順に印を付けます。プロバイダーのログインページが表示されれば、ブラウザ側の経路が機能した証拠です。Rails がコールバックを受け取れば、ブラウザが戻ってきた証拠です。その後のトークンリクエストこそ、Rails プロセスからのプロキシ接続、チャレンジ、プロバイダーの応答を調べる箇所です。