Cookie のキーをデータベースで見つかったキーと比較して、再訪問者がサイトに自動的にログインできるようにしたいと考えています。これは、データベースのキーと Cookie が特定のユーザーに関連付けられることを意味します。
私の質問は、ユーザー名がパスワードとともに保存されているテーブルにキーを保存するか、別のテーブルを作成して、関連付けられたキーとタイムスタンプを持つユーザー名を作成することです。
ここでは複雑さが問題です。さらに、innodbまたはIsamが上記に適しているかどうかを見つけようとしています。
問題をさらに複雑にしているのは、アプリケーションがどのくらい大きくなり、それがデータベースの設計にどのような影響を与えるかを予測するのが難しいという事実です。適切な解決策にたどり着くのは早ければ早いほどよい
これにどのようにアプローチするかについて、いくつかの考えとアイデアでこれに答えます。
これを行うときに最初に考慮すべきことは、他のサイトがどのように行うかです。
ご覧のように、多くのサイトでは永続的なログインがユーザーの操作を制御することを許可しているだけではなく、実際には永続的なログインが返されることはまれであり、ユーザーが完全にログインすることさえありません。代わりに、ほとんどのサイトで実装されているのは 2 層のログイン システムで、Cookie ユーザーとしてサイトを表示できますが、再度ログインしなければ編集することはできません。
ここに来ればすぐに気がつきます。これらのサイトの多くは、ブラウザー セッションの有効期限のみについて Cookie の有効期限を気にしません。永続的な Cookie の有効期限が短いことはめったにないため、この点はあまり役に立ちません。@pyruva が述べているように、誰かの Cookie を盗んで、サイトをそのように表示するのは簡単です。これは Facebook で常に発生しています (その方法についてのビデオ チュートリアルを見つけることもできます)。
したがって、最初に覚えておくべきことは、永続的なログインは本質的に安全ではないということです。安全にする方法は、通常、2 層認証システムなどを実装することにより、アプリケーション ロジック内にあります。
絶対にしてはいけないことの 1 つは、ユーザー名やパスワードなど、ユーザーに関する個人を特定できる情報を、ハッシュ形式であっても、その Cookie に保存することです。より良い方法は、ランダムに生成されたトークン (ここでは OAuth2 を考えてください) を使用して、最初にサーバーとハンドシェイクすることです。
もちろん、もう 1 つ考慮する必要があるのは、一般的な Cookie の保護です。これについては Google で多くのリソースを見つけることができますが、非常に役立つリンクが 1 つあります。
うまくいけば、これに取り組む方法についての方向性とヒントが得られるはずです.
サイトにアクセスするすべてのユーザーは、Cookie に関して実質的に 2 つのセッションを持っています。ブラウザ セッションがあり、ブラウザを閉じると、ブラウザから Cookie が削除されます (通常、HTTP ヘッダー内の有効期限は 0 として示されます)。
次に、持続セッションがあります。現在実装しようとしているもので、実際に有効期限が切れる前に Cookie が何年も存続する可能性があります。
これが、ブラウザの有効期限の意味です。そのため、ほとんどのサイトには、ブラウザーを閉じると削除される一時的な Cookie が格納されています。これらの Cookie は通常、セッションを自分のものにするために使用されます。
サイトが Cookie の有効期限を気にする場合、コンピューターで 2 年間有効な Cookie を格納しません。誰かが期限切れの Cookie を使用してあなたのアカウントを悪用しようとしている場合、Cookie はまだ完全に有効であるため、運が悪いことになります。これはより大きなセキュリティ上の脅威ですが、私の主張を証明しています。