22

HttpWebRequest を介して別のサーバーに GET 要求を送信する ASP.NET MVC アクションがあります。元のアクションのリクエストのすべての Cookie を新しいリクエストに含めたいと思います。元のリクエストの一部の System.Web.HttpCookies には空のドメイン値 (つまり "") がありますが、これは明らかに問題を引き起こしません。これらの各 Cookie の名前、値、パス、およびドメインを使用して System.Net.Cookie を作成し、それを要求の CookieContainer に追加すると、次のエラーが発生します。

"System.ArgumentException: パラメーター '{0}' を空の文字列にすることはできません。パラメーター名: cookie.Domain"

同じエラーをスローするコードを次に示します (Cookie が追加された場合)。

var request = (HttpWebRequest)WebRequest.Create("http://www.whatever.com");
request.Method = "GET";
request.CookieContainer = new CookieContainer();
request.CookieContainer.Add ( new Cookie ( "MyCookieName", "MyCookieValue", "/", "") );

編集

元のHttpCookieのnullまたは空の文字列値の代わりに、ドメインに「localhost」を使用して、これを修正しました。では、CookieContainer で空のドメインが機能しないのはなぜでしょうか? また、HttpCookie は空の値を使用して localhost を示しますか? それとも、この問題の別の修正を見つける必要がありますか?

4

4 に答える 4

9

免責事項:

@feroze が以前に述べたように、Cookie のドメインを localhost に設定してもうまくいきません。HTTP リクエストを外部ドメインにトンネリングできるヘルパーを作成していると仮定しています。これはベスト プラクティスではなく、多くの場合は不要であることに注意してください (つまり、jQuery には多くの優れたクロスドメイン サポートが組み込まれています。新しいCORS 仕様も参照してください)。ただし、これを行うと行き詰まる場合があります (つまり、外部リソースが XML のみであり、CORS をサポートしないサーバー上にある場合)。

Cookie ドメインとその仕組みに関する背景情報:

ウィキペディアの HTTP Cookie: Domain and Path をまだ見ていない場合は、知っておく必要のあるほとんどすべての情報がそこにあります。

Cookie を評価するとき、ドメインとパスは、クライアント (「ローカル」リクエスター) と Web サーバー (「外部」レスポンダー) の両方で考慮されます。クライアントがリソースを要求するとき、クライアントは、要求されている URI の Domain (またはより一般的な親 domain ) および Path (またはより一般的な親パス) と一致する Cookie のみを送信する必要があります。

Web ブラウザはこれを正しく処理します。たとえば、Web ブラウザにドメイン「localhost」の Cookie があり、「google.com」をリクエストしている場合、「localhost」ドメインの Cookie はリクエストで「google.com」に送信されません。-- 実際、最新のブラウザのほとんどは、それらを送信しないだけでなく、受信した Set-Cookie 応答ヘッダーでそれらを完全に無視します (これらはサードパーティ Cookie と呼ばれます。 Web ブラウザーを使用することは、プライバシー/セキュリティ上の大きな懸念事項です。使用しないでください!)。

それは他の方向にも機能します-クライアントがリクエストにサードパーティのCookieを含める可能性は低いですが、含まれている場合、外部Webサーバーはそれを無視することになっています(正しいドメイン/パスのCookieでさえも)悪名高いスーパー Cookie の問題を防ぐため (つまり、「example.com」をホストする Web サーバーは、その親ドメイン「.com」に属する Cookie を無視する必要があります。「.com」は「パブリック サフィックス」であるためです))。 .

あなたがしなければならないこと[しなければならない場合]:

私がお勧めする一連のアクションは、クライアントの Cookie (私は MVC の専門家ではありませんが、通常の ASP.NET ではこれは Request.Cookies にあります) を読み取るときに、それらをループ処理することです (必ずフィルターで除外してください)。独自のサイトの正当な Cookie、特に SessionId など -- または Path を適切に使用して、最初からこのページに送信されないようにします)、送信リクエストの Cookie コレクションに一度に 1 つずつ追加し、ドメインを「 www.whatever.com" (あなたの例によると、これを動的に行う場合は、URL を新しい Uri() オブジェクトにロードし、.Host プロパティを使用します)、Path を "/" に設定します。-- これにより、外部 Web サーバーへの発信要求の「Cookie」ヘッダーが作成されます。

そのリクエストがサーバーに返されたら、新しい Cookie の着信応答を確認する必要があります。これらの Cookie は、前の段落で説明したのとほぼ同じタイプのループで再パッケージ化してクライアントに送り返すことができます。 Host を Request.Url.Host に書き換えたいと思うでしょう -- そして、パススルー ページへのパスが静的でない限り、パスを "/" に戻す必要があります (あなたがMVC を使用する場合)、たとえば Request.Url.AbsolutePath に設定する必要があります。

ハッピーコーディング！

編集: また、送信リクエストのX-Forwarded-Forタグを設定して、呼び出している Web サイトが、Web サーバーがそれらからスパムを送信している単一のクライアントであると認識しないようにする必要があります。

于 2012-10-14T05:11:23.130 に答える
3

いくつかの背景

これは、CookieContainer が複数の HttpWebRequest で再利用されるように設計されたクライアント側コンテナーであるためです。これを再利用すると、リモート ホストによって設定された Cookie が、同じホストを対象とする後続のすべての HttpWebRequests とともに送り返されるという、期待される Cookie の動作が提供されます。

再利用の結果、CookieContainer には、複数のリクエストやホストからの Cookie が実際に含まれる場合があります。

したがって、コンテナー内のどの Cookie を特定の HttpWebRequest でホスト (ドメイン) に送信する必要があるかを判断するために、CookieContainer は Domain プロパティと Path プロパティを調べます。

そのため、CookieContainer内の Cookie には有効なドメインが必要です。

逆に、サーバー側のCookie は別のタイプのCookieCollectionを介して配信されます。CookieCollection は、追加のロジックを持たない単純な Cookie のリストです。

具体的には、あなたの場合、CookieCollection から CookieContainer に Cookie をコピーするときに、すべての Cookie の Domain プロパティを、リクエストを転送するドメインに設定する必要があります。 .

于 2013-05-28T22:56:21.050 に答える
-1

Cookieをローカルホストに送信しようとしていますよね？

自分のマシンに本名を付けるようなことをしてみませんか。

  1. ホストファイルを編集し、「127.0.0.1myname.com」という行を追加します
  2. myname.comを使用してテストします。これは実際にはローカルホストです。

ブラウザまたはアプリは違いを認識せず、Cookieが属する場所である場合はmyname.comにCookieを送信します。

詳細情報：

  1. WindowsのHostsファイルはC：\ Windows \ System32 \ drivers \ etc\hostsにあります
于 2011-02-23T10:04:29.000 に答える