web-dev-qa-db-ja.com

ブラウザが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の wiki ページを読むと、キャッシュサーバー（私の場合、私は自分の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)

もしyesもしこれが私を悩ませているなら、それは

なぜ？は、マシン上でローカルに実行しているサーバーとアクセスしているサーバーで同じです（つまり、_X-Forwarded-For_がリクエストヘッダーに表示されない） _http://localhost:3000_のようなブラウザ経由で

httpbrowserhttp-headersclient-server
11
Ratatouille

X-Forwarded-Forは RFC 2616 Section 5. で指定されている標準のリクエストヘッダーではなく、プロトコルの標準リクエストヘッダーに対応します（RFCで指定されています）。

  • 受け入れる
  • Accept-Charset
  • Accept-Encoding
  • 受け入れ言語
  • 認可
  • 期待する
  • から
  • ホスト
  • イフマッチ
  • If-Modified-Since
  • If-None-Match
  • If-Range
  • If-Unmodified-Since
  • マックスフォワード
  • プロキシ承認
  • 範囲
  • リファラー
  • TE
  • ユーザーエージェント

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

トリッキーなことは、あなたが見ることを期待しているヘッダーは、あなたがあなたのサービスと呼び出し元との間に適切な契約がない限り、あなたが必ずしも受け取ることを期待しているはずのヘッダーではないということですリクエストヘッダーでX-Forwarded-For値が指定されることを期待する必要があることを示すHTTProtocolとは異なります。他の人がすでに述べたように、XFFヘッダーは通常、プロキシサーバーまたはロードバランサーによって設定され、プロキシを介して動作している実際のリクエスターが誰であるかを示します。

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

HTTProtocolが匿名性について言っていることは次のとおりです。

リンクのソースはプライベートな情報であるか、それ以外の場合はプライベートな情報ソースである可能性があるため、Refererフィールドを送信するかどうかをユーザーが選択できるようにすることを強くお勧めします。たとえば、ブラウザクライアントには、リファラーと送信元の情報の送信をそれぞれ有効/無効にする、オープン/匿名で閲覧するためのトグルスイッチがあります。

クライアントは、（非セキュア）にリファラーヘッダーフィールドを含めないでください。
参照ページが安全に転送された場合のHTTPリクエスト
プロトコル。

HTTPプロトコルを使用するサービスの作成者はGETを使用してはいけません（SHOULD NOT）
機密データの提出用のフォーム。これにより、
このデータはRequest-URIでエンコードされるため。多くの既存の
サーバー、プロキシ、ユーザーエージェントは、リクエストURIを
第三者に見える可能性がある場所。サーバーが使用できる
代わりにPOSTベースのフォーム送信...

すべてのリクエストで送信される、ユーザーがカスタマイズした複雑なAcceptヘッダーフィールドは、特にこれらに品質値が含まれている場合、比較的信頼性が高く存続期間の長いユーザー識別子としてサーバーで使用できます。このようなユーザーIDを使用すると、コンテンツプロバイダーはクリックトレイル追跡を行うことができ、協調するコンテンツプロバイダーはクロスサーバークリックトレイルまたは個々のユーザーのフォーム送信に一致させることができます。プロキシの背後にない多くのユーザーの場合、ユーザーエージェントを実行しているホストのネットワークアドレスも、長期間有効なユーザー識別子として機能します。プロキシを使用してプライバシーを強化する環境では、ユーザーエージェントは、ヘッダーの受け入れ構成オプションをエンドユーザーに提供する際は慎重にすべきです。極端なプライバシー対策として、プロキシはリレーされたリクエストのAcceptヘッダーをフィルタリングできます。高度なヘッダー設定機能を提供する汎用ユーザーエージェントは、関与する可能性のあるプライバシーの喪失についてユーザーに警告する必要があります。

個人的には、401.2で要求をバウンスし、WWW-Authenticate応答ヘッダーを介して要求者をチャレンジ画面にルーティングし、サイトへの匿名アクセスが許可されないことを通知します。これはWWW-Authenticateヘッダーを使用する粗雑な方法の一種ですが、X-Forwarded-Forヘッダーが実際のリクエスターを確認および識別し、public non-を許可しているようですanonymousサービスへのアクセス。私にとって、それは認証の問題です。

10
K. Alan Bates
  • ISPプロバイダーはX-Forwarded-Forを追加しません。
  • X-Forwarded-Forは、エンドユーザーがプロキシ/バランサーの背後にあるアプリケーションを特定するためのものではありません。
  • X-Forwarded-Forは、プロキシ/バランサの背後にあるアプリケーションがユーザーを識別するためのものです。

例：Webアプリケーション（php、Javaなど）があり、httpサーバー（Apache、nginxなど）もあるとします。

  1. ユーザーはhttpサーバーに要求を行います。
  2. HTTPサーバーは、ユーザーIPとしてX-Forwarded-Forを使用してWebアプリケーションにリクエストをリダイレクトします。
  3. あなたのWebアプリケーションは、それがhttpサーバーの背後にあることを知っているため、ユーザーipとしてX-Forwarded-Forを読み取ります。
4
Krzysztof Bogdan

X-Forwarded-Forが最初に表示されるのはなぜですか。 localhostで実行されているWebサーバーに接続しているため、ISPプロバイダーは一切関与していません。 ISPを介してWebサーバーに接続している場合でも、X-Forwarded-Forをリクエストに追加することはほとんどありません。 X-Forwarded-Forは通常、HTTPプロキシサーバーまたはロードバランサーによって追加されますが、どちらも経由していません。 X-Forwarded-ForがWebブラウザーに含まれることはありません。

1
Remy Lebeau