ThinkPHP でのログイン検出を研究しています。ログインが成功し、セッションが保存されると、次の 2 つのフォームが表示されます。 2 番目の方法:
Session::set (C('USER_AUTH_KEY'),$username);
2 番目の方法では、設定ファイルに 'USER_AUTH_KEY'=>'authId' を記述する必要があります。
の違いを説明してください。 2つの方法? USER_AUTH_KEY が 2 番目のタイプに設定されているのはなぜですか?
1 つのドメイン名で複数の thinkphp ログインを実行するときに、ユーザー ID を保存するセッションでの競合を防ぐためだと言う人もいます。しかし、よく考えてみると、これを行わないとどのような競合が発生するかわかりません。2 つのセッションのセッション ID は同じになりますか?
主にセッションの暗号化に使用されると思います。
実際には、両方ともセッションを設定していますが、後者のセッションのキーは設定ファイル内で固定されているため、多くの場合、設定ファイルの USER_AUTH_KEY 設定セクションの値を変更するだけで済みます。セッションのキーを変更します。
セッションを使用すると、最初の階で述べた競合が発生しますか?
どこを暗号化するか?使用時にセッションを暗号化する必要がありますか?
主にセッションの暗号化に使用されると思います。
どこを暗号化するか?使用時にセッションを暗号化する必要がありますか?
データの暗号化は良い習慣です。例: md5(sessionid+'USER_AUTH_KEY')。この値は、ユーザーの種類に応じて異なる USER_AUTH_KEY を使用できます。
これらはパスワードで非常に一般的に使用されており、プレーンテキストのパスワードをデータベースに保存したいと思う人はいません。
私の説明は完了しました。お役に立てば幸いです。
主にセッションの暗号化に使用されると思います。
どこを暗号化するか?使用時にセッションを暗号化する必要がありますか?
データの暗号化は良い習慣です。例: md5(sessionid+'USER_AUTH_KEY')。この値は、ユーザーの種類に応じて異なる USER_AUTH_KEY を使用できます。
これらはパスワードで非常に一般的に使用されており、プレーンテキストのパスワードをデータベースに保存したいと思う人はいません。
私の説明は完了しました。お役に立てば幸いです。
セッションをデータベースに置かずにサーバーのハードディスクまたはキャッシュに直接置いた場合、暗号化は無意味ですよね?
ああ、元の投稿者がこれに苦労していることがわかりました。同じマシン上であなたが言及したようなセッションの競合はありません。元の投稿者はセッションの原則を注意深く検討することをお勧めします。
まとめると、私は二階の人の言うことに賛成です。上記の投稿も私に大きなインスピレーションを与えてくれました、ありがとう!また、縛りは必要でしょうか?どうやって分散させるのか?
はい、閉店しました。