すべての CI ユーザーは、デフォルトでセッションが Cookie に保存されることを知っています。
しかし、この実装のポイントは正確には何ですか? 私は本当に正当な理由を見つけることができません。
OK、共有サーバーでは人々がセッションファイルにアクセスできるかもしれませんが、クライアント側はどうですか? Cookie のデータも変更でき、「一方向」の方法である場合、サーバー側のセッション Cookie のデータを検証するにはどうすればよいですか? Cookie でサイズの問題が発生する可能性があることは言うまでもありません。
私はデータベースの方法を認識していますが、完全に制御できる専用サーバーにいて、非常に単一のページでセッションテーブルをクエリするためにdbリソースを浪費したくない場合は、より柔軟/便利ではなかったでしょうデフォルトで従来の PHP メソッドを提供するので、Cookie の ID でデータを検証できますか?
CSRF 保護を使用して Cookie を暗号化し、Cookie 操作に対してシステムを強化できます。
ただし、セキュリティが心配な場合は、絶対にセッションにデータベースを使用する必要があります。大量のユーザーがいない限り、データベースへのヒットはごくわずかです。大量のユーザーがいる場合は、セッション ルックアップとしてワークロードを分散することを考える時間は、ほとんど心配ありません。
クライアントの Cookie は、状態のためのものです。ログインフォームの「remember me」やページレイアウトなどに使用できます。アプリケーションを保護するために使用しないでください。
アプリケーションがセッション ID を保存する場所がないため、db セッションを使用していない場合、Cookie を介してセッションを確認することはできません。
詳細については、 http://ellislab.com/codeigniter/user-guide/libraries/sessions.htmlを参照してください。
Cookie ベースのセッションは、セッション情報を保存するための軽量で高速なメカニズムを提供します。また、安全です。各 Cookie は、強力な AES-256 暗号化を使用して暗号化されます。ただし、Cookie には 4 キロバイトのストレージ制限があるため、セッションに大量のデータを保存する場合は、別のドライバーを使用することをお勧めします。データは構成内のハッシュに基づいて暗号化され、CI はセキュリティを強化するために断続的にハッシュの更新も実行します。セッションを Cookie またはデータベースに保存することも、サーバー ファームまたは高負荷のクラスターに適しています。多くの大企業やその他のトラフィックの多い Web サイトは、この戦略をセッションに使用しています。
これは、4kbのデータに制限され、データクライアント側があり、ページの読み込みごとにデータがREQUESTとして表示されることへの懸念を理解していると言われています。ただし、デフォルトの PHP セッションを手動で使用したり、独自のセッション ライブラリを展開したりすることを妨げるものは何もありません。