[解決済み] X-Forwarded-Forヘッダーが表示されないブラウザの理由

質問

備考 : 質問の全文をお読みください。

なぜブラウザで X-Forwarded-For ヘッダが表示されます。

ちなみに、私のリクエストヘッダは以下のような感じです。

Request URL:http://localhost:3000/users/sign_in
Request Method:GET
Status Code:304 Not Modified

リクエストヘッダ。

Accept:text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Accept-Encoding:gzip,deflate,sdch
Accept-Language:en-GB,en-US;q=0.8,en;q=0.6
Cache-Control:max-age=0
Connection:keep-alive
Cookie:undefined=0; poasterapp=s%3A4faaa6b1723e7c6fbd949083532c52598652547b.sNX%2BKOEed2TEQkQN7I7K5lgpoHMRpwerKFvUegMnTVI; _minerva_session=BAh7CUkiD3Nlc3Npb25faWQGOgZFRkkiJWEyM2Q0ZTViMWEyODBiYmFmODEwZTJhZmUwNWU5ODk5BjsAVEkiE3VzZXJfcmV0dXJuX3RvBjsARiIGL0kiCmZsYXNoBjsARm86JUFjdGlvbkRpc3BhdGNoOjpGbGFzaDo6Rmxhc2hIYXNoCToKQHVzZWRvOghTZXQGOgpAaGFzaHsGOgphbGVydFQ6DEBjbG9zZWRGOg1AZmxhc2hlc3sGOwpJIgAGOwBUOglAbm93MEkiEF9jc3JmX3Rva2VuBjsARkkiMUN0Uk56SXU0dUdIdzgwcFZJM3R0L2N4dlovRllTSGRrQ2o1R0VVanhIaVk9BjsARg%3D%3D--6bd89ce9d29e9bdcf56573f9a153dc663a8fe755
Host:localhost:3000
If-None-Match:"785d34e3998360353567fc710af123fb"
User-Agent:Mozilla/5.0 (Macintosh; Intel Mac OS X 10_7_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/32.0.1700.102 Safari/537.36

レスポンスヘッダ (必要ありませんが、それでも)

Cache-Control:max-age=0, private, must-revalidate
Connection:close
ETag:"785d34e3998360353567fc710af123fb"
Server:thin 1.5.0 codename Knife
Set-Cookie:_minerva_session=BAh7CEkiD3Nlc3Npb25faWQGOgZFRkkiJWEyM2Q0ZTViMWEyODBiYmFmODEwZTJhZmUwNWU5ODk5BjsAVEkiE3VzZXJfcmV0dXJuX3RvBjsARiIGL0kiEF9jc3JmX3Rva2VuBjsARkkiMUN0Uk56SXU0dUdIdzgwcFZJM3R0L2N4dlovRllTSGRrQ2o1R0VVanhIaVk9BjsARg%3D%3D--dfb3ce9f5c97463cfcd0229a133654e6cc606d98; path=/; HttpOnly
X-Request-Id:41a6f3062dc8bc36b7b3eae71dc5075d
X-Runtime:89.238257
X-UA-Compatible:IE=Edge

今言ったように、私は何も見ていません。 X-Forwarded-For（転送先 リクエストヘッダに

を読み解く。 ウィキ のページがあります。 X-Forwarded-For キャッシュサーバ（私の場合、ISPプロバイダと思われる）が行っているような気がします。 so am I safe to believe that the **X-Forwarded-For** headers is something that is added at the caching server side (ISP provider)

もし はい その時、この人は私を悩ませています。

なぜ は、同じように真（すなわち X-Forwarded-For のようにブラウザからアクセスした場合、リクエストヘッダーに表示されません。 http://localhost:3000

どうすればいいですか？

で指定されているように、X-Forwarded-Forは標準的なリクエストヘッダではありません。 RFC2616セクション5.3 これはプロトコルの標準リクエストヘッダに対応するもので、（RFCで規定されているように）次のとおりです。

• 受入
• Accept-Charset
• エンコード
• 言語を受け入れる
• 認証
• 期待する
• から
• ホスト
• 一致した場合
• 変更された場合
• 一致しない場合
• 範囲指定
• 変更されない場合-以降
• 最大転送量
• プロキシ認証
• 範囲
• リファラー
• TE
• ユーザーエージェント

受信したリクエストにカスタム [X-Forwarded-For] ヘッダーを持たせるには、呼び出し元のクライアントがそのリクエストに明示的に追加する必要があります。 そのヘッダーが表示されない理由の最も簡単な説明は、リクエストを送信するクライアントが手動でそれを追加しなかったということです。

厄介なのは、あなたが見ることを期待しているヘッダーが は、必ずしも受け取ることを期待すべきヘッダーではありません。 ただし、HTTProtocolとは別に、あなたのサービスと呼び出し元の間で、リクエストヘッダにX-Forwarded-For値が指定されることを期待することを示す契約が結ばれている場合は、この限りではありません。 他の人がすでに述べているように、XFFヘッダーは通常、プロキシサーバーやロードバランサーによって設定され、プロキシを通して行動している本当の要求者が誰であるかを示すものです。

サービスプロバイダとして、すべてのリクエストに [X-Forwarded-For] ヘッダを設定することを要求する場合、サービスポリシーレベルでそれを強制する必要があります。 プロキシIPで誰をシールドしているかを特定しないプロキシアカウントにサービスを提供したくない場合は、403 Forbiddenでリクエストをバウンスしてください。 これらのリクエストを処理しなければならないが、このヘッダが設定されていることに依存している状況であれば、彼らのエラーを伝え返すことができるカスタムプロセスを考え出す必要があるでしょう。

匿名性についてのHTTProtocolの説明を以下に示します。

リンク元が個人情報である可能性や、リンク元が個人情報である可能性があるので 個人的な情報源であることを明らかにすることは、非常に重要です。 を選択できるようにすることを推奨します。 Refererフィールドが送信されます。例えば、ブラウザのクライアントに オープン/アノニマスブラウジングのトグルスイッチは、以下のようになります。 は、それぞれRefererとFromの送信を有効/無効にする。 の情報を提供する。

クライアントは、Refererヘッダーフィールドを(非セキュアな)HTTPサーバーに含めるべきではありません(SHOULD NOT)。
HTTPリクエストで、参照ページが安全な
プロトコルを使用します。

HTTPプロトコルを使用するサービスの作者は，GET/PROFILEプロトコルを使用すべきではありません。
をベースにしたフォームで機密データを送信します。
は、このデータがRequest-URIにエンコードされる原因となる。既存の多くの

サーバ、プロキシ、およびユーザエージェントは、リクエストURIを何らかの方法で記録します。
第三者から見えるかもしれない場所。サーバーは
POSTベースのフォーム送信の代わりに ...

ユーザーがカスタマイズした精巧なacceptヘッダーフィールドをすべてのリクエストで送信する。 特にQualityの値が含まれている場合、サーバーはそれを利用することができます。 を、比較的信頼性が高く、長期に渡って使用できるユーザー識別子として使用することができます。このようなユーザー は、コンテンツ・プロバイダーがクリック・トレイルを追跡することを可能にする。 また、協力するコンテンツプロバイダーは、サーバー間の のクリック痕やフォームの送信など、個々のユーザーごとに異なる。なお プロキシを経由していない多くのユーザーは、ホストのネットワークアドレス ユーザーエージェントを実行している場合、長期的なユーザー を識別することができます。プロキシを利用する環境において プライバシーを守るために、ユーザーエージェントは控えめにAccept ヘッダーの設定オプションをエンドユーザーに提供します。極端なプライバシー保護として の対策として、プロキシは中継されるリクエストのacceptヘッ ダーをフィルタリングすることができる。 高度なヘッダーを提供する汎用のユーザーエージェントがある。 を設定できるように、プライバシーが失われる可能性があることをユーザーに警告すべきです。 を含む。

個人的には、401.2でリクエストをバウンスし、WWW-Authenticateレスポンスヘッダを介して、サイトへの匿名アクセスが許可されないことを通知するチャレンジスクリーンにリクエスタを誘導します。 これはWWW-Authenticateヘッダーの使い方の一種ですが、X-Forwarded-Forヘッダーが本当の要求者を認識し識別することを期待しているようであり、また、次のことを許可しているようです。 公開 非匿名 にアクセスすることができます。私にとっては、これは認証に関する問題です。