2016-11-03 9 views
0

誰もが、Cookieを保存するためにドメインに2つのドットが必要であると主張しますが、それは真実ではありません。なぜなら、ChromeはCookieのCookieヘッダーを介して受け取った "__RequestVerificationToken"ただし、他のCookieの保存を拒否します。私は文字通り、実質的に同じSet-Cookieヘッダーで実質的に同一のCookieを送信していますが、Chromeはそれを保存することを拒否しています。パスは "/"で、もう一方と同じです。ドメインは設定されていません。唯一の違いは名前です。 Chromeは「__RequestVerificationToken」に何らかの特別扱いをしていますか?なぜChromeはlocalhostに対して__RequestVerificationCookieを格納しますが、他のCookieは格納しませんか?

+0

HttpCookie.ExpiresをDateTime.MinValueに設定した結果、格納されているようです。これにより、Cookieの書き込みに「expires」文字列が含まれなくなるため、CookieがセッションCookieになり、localhostに格納されます。なぜそれらのクッキーが保存されているのかわかりません – Triynko

答えて

0

Chromeは「localhost」の「セッション」Cookieを保存しますが、「永続的」Cookieは保存しないようです。なぜ "セッション"クッキーの例外を作るのか分かりませんが、クッキーは第2レベルのドメイン(少なくとも2つのドットがあるlocalhostではないドメイン)のために保存されているため、 "永続的な"クッキーは保存されません。

「永続的な」クッキーは有効期限を設定するクッキーですが、直感的ではありませんが、「セッション」クッキーとは異なり、ブラウザが再起動しても「永続的」な意味を持ちますブラウザが閉じると削除されます。実際には、Chrome/Firefoxは一般的に、ブラウザが終了したときにセッションクッキーを削除しないため、「常時中断した場所から続行」や「ブラウザの再起動時にタブを復元する」などの機能により、

また、次のような利点があるため、あらゆる種類のセッションまたは認証Cookieに対して有効期限を設定することはできません。1. localhostで動作します。2.それがより安全ですブラウザが終了したときに削除される可能性があります。3.ユーザがブラウザを設定している場合は、ブラウザセッション間で存続するため、長いタイムアウトを設定する必要はありません。とにかく、サーバー側のセッションと同期する別の値であるため、クッキーの有効期限を設定しても、何の役にも立たないので、値はCookieと共にサーバーに送信されないので、役に立たないし、まったくトークンのサーバー側の有効期限(セッションまたはデータベースに格納されています)は、とにかく信頼できます。セッションや認証関連のCookieに期限を設定しないでください。

関連する問題