以下の回答はずっと前に書かれたものです。現在、良くも悪くも、さまざまな国の法律により、少なくともユーザーがそのようなメカニズムに同意する機会が得られるまで、必要な場合を除いて Cookie を要求しないことが適切な慣行 (または法的要件) になっています。
ユーザーがログインやカートへの追加など、セッションを開始する何かを行おうとしている場合にのみ、これを行うことをお勧めします。そうしないと、対処方法によっては、Cookie をサポートしていないユーザー (またはボット) のサイト全体へのアクセスがブロックされる可能性があります。
最初に、サーバーは通常どおりログイン データをチェックします。ログイン データが間違っている場合、ユーザーは通常どおりそのフィードバックを受け取ります。正しい場合、サーバーはすぐに Cookie と、その Cookie を確認するように設計されたページへのリダイレクトで応答します。これは、同じ URL である可能性がありますが、クエリ文字列にフラグが追加されている場合があります。その 2 番目のページが Cookie を受信しない場合、ユーザーは、ブラウザーで Cookie が無効になっているためログインできないというメッセージを受け取ります。
すでにログイン フォームの Post-Redirect-Get パターンに従っている場合、この Cookie の設定とチェックによって追加のリクエストが追加されることはありません。既存のリダイレクト中に Cookie を設定し、ロードする宛先によってチェックすることができます。リダイレクト後。
ここで、すべてのページの読み込み時以外に、ユーザーが開始したアクションの後にのみ Cookie テストを行う理由について説明します。サイトがすべてのページに Cookie テストを実装しているのを見てきましたが、これがサイトをクロールしようとする検索エンジンなどに影響を与えることに気づいていませんでした。つまり、ユーザーが Cookie を有効にしている場合、テスト Cookie は 1 回設定されるため、要求した最初のページでリダイレクトに耐えるだけでよく、それ以降はリダイレクトはありません。ただし、ブラウザーや、検索エンジンなど、Cookie を返さない他のユーザー エージェントの場合、すべてのページが単純にリダイレクトされる可能性があります。
Cookie のサポートを確認するもう 1 つの方法は、Javascript を使用することです。この方法では、必ずしもリダイレクトは必要ありません。Cookie を書き込んですぐに読み戻して、保存されてから取得されたかどうかを確認できます。これの欠点は、クライアント側のスクリプトで実行されることです。つまり、サーバーに戻るために Cookie がサポートされているかどうかについてのメッセージが引き続き必要な場合は、Ajax 呼び出しなどを使用してそれを整理する必要があります。
私自身のアプリケーションでは、ユーザーがログインする前にログイン画面にランダムなトークンを含む Cookie を設定し、ユーザーがログインを送信するときにそのトークンをチェックすることで、CSRF 攻撃の一種である「ログイン CSRF」攻撃に対する保護を実装しています。詳細。Google からのログイン CSRF の詳細をお読みください。これの副作用は、彼らがログインした瞬間に、その Cookie の存在を確認できることです。追加のリダイレクトは必要ありません。