【ユーザーログイン判定】PHPの判定処理は正しいですか？毎回データベースにクエリを実行し、COOKIE を保存します

ユーザーがログインしているかどうかを判断するための独自の PHP を作成しました:

[プロセス]
1 まず cookie('uid') があるかどうかを判断します && cookie('uid') ループから抜け出さない場合検出
2 存在する場合は、データベースに接続して uid に対応するレコードをクエリします。レコードが変更されていない場合は、ループ検出から抜け出し、すべてのユーザー Cookie をログアウトします
3 存在する場合は、Cookie('upwd ')== md5($rs[pwd].cookie('salt'))、そうでない場合は、パスワードが変更されたため、再度ログインする必要があることを示すメッセージが表示されます
4 等しい場合は、 cookie('email') == md5($rs[email]) を確認してください。これらが等しくない場合は、電子メールが変更されたため、再度ログインする必要があるというメッセージが表示されます
5 等しい場合 => ;このユーザーは現在ログインしているユーザーです。

でも！
[問題]
1 毎回データベースに接続する必要がある。データベース クエリを減らすことがユーザー最適化の鍵です。毎回データベースにクエリを実行すると、パフォーマンスに大きな影響を与えます。
2 最適化する方法は何ですか? このログイン判定プロセスは間違っていますか?

[別のアイデア]
1 SESSION に保存し、$uid、$uname、$lastactive (最終応答時間) をセッションに保存します。
2 time()-$lastactive > 3600 を検出するための session('uid') && session('uname') がある場合は、データベースに接続してクエリします (上記の Cookie によって判断されます)。それ以外の場合は、(セッションの保存場所 php.ini デフォルト設定の場所)

【質問】
1 SESSIONに保存した場合、同時実行性が高い場合に影響はありますか？

ディスカッション (解決策) への返信

2 番目の解決策を使用する場合、高い同時実行性が懸念されます
では、1 番目の解決策を使用する場合、高い同時実行性を考慮する必要はありません。

最初のソリューションでは、ユーザーのパスワードとメールアドレスが Cookie に保存されています。このデータは常にネットワーク上で動作しています。安全だと思いますか?

データベースは広範囲である必要があります
ファイル システムベースのリレーショナル データベース (SQL) は若干遅いかもしれませんが、すべてメモリベースのメモリ テーブルを提供します
データベースには別のブランチがあることは言うまでもなく、メモリベースの noSQL です
したがってデータベースクエリによって生じる追加のオーバーヘッドは無視できます

ユーザーがログインしているかどうかを判断するプロセスは次のとおりです:
cookie('uid') が存在しない場合は、ログイン処理のリクエストに進みます
それ以外の場合は、データベースにクエリを実行し、前回の UID のログイン場所は今回と同じです:
同じ場合は確認します
異なる場合はプロンプトが発行され、条件付き転送にはログイン処理が必要になります

2 番目のオプションを使用する場合、あなたは高い同時実行性を懸念しています
それなら、高い同時実行性を考慮せずに最初のオプションを使用してください。

最初のソリューションでは、ユーザーのパスワードとメールアドレスが Cookie に保存されています。このデータは常にネットワーク上で動作しています。安全だと思いますか?

データベースは広範囲である必要があります
ファイル システムベースのリレーショナル データベース (SQL) は若干遅いかもしれませんが、すべてメモリベースのメモリ テーブルを提供します
データベースには別のブランチがあることは言うまでもなく、メモリベースの noSQL です
したがってデータベースクエリによって生じる追加のオーバーヘッドは無視できます

ユーザーがログインしているかどうかを判断するプロセスは次のとおりです:
cookie('uid') が存在しない場合は、ログイン処理のリクエストに進みます
それ以外の場合は、データベースにクエリを実行し、 UID の前回のログイン場所は同じです 今回も同じです:
同じであれば確認します
異なる場合はプロンプトを送信し、条件付きでログイン処理のリクエストに移行します

次に、次のことを行う必要があります毎回 MYSQL データベースにクエリを実行します。ログインアドレスによると、通常はIPです。

ユーザーソースのチェックは、CSRF 攻撃を防ぐためです
通常、書き込みアクションを使用するページでのみ行われます

これが私が行う方法です。
1. ユーザーはログイン後、データベースに接続し、成功したかどうかを判定します。成功した場合は、セッションと Cookie にユーザー ID、ユーザー名などの判断に必要な情報が書き込まれます。一定期間 (たとえば、ログイン時に 1 日から 2 週間)、さらに、Cookie に保存されたデータの json_encode を作成し、それを暗号化します。
たとえば、{"uid":1,"username":"fdipzone"} は、可逆文字列に暗号化されます。

2. ユーザーが訪問すると、次のような状況になります
1. セッションが存在するかどうかを判断します -> はい -> パス
2. セッションが存在するかどうかを判断します -> いいえ -> Cookie が存在するかどうかを判断します-> はい-> Cookie の復号化が成功したかどうかを判断します-> はい-> セッションに Cookie を書き込みます-> 合格
3. セッションが存在するかどうかを判断します-> いいえ-> Cookie が存在するかどうかを判断します-> はい-> Cookie の復号化が成功したかどうかを判断します -> いいえ - > セッションが存在するかどうかを判断します - > いいえ - >ログインページへ

これが私のやり方です。
1. ユーザーはログイン後、データベースに接続し、成功したかどうかを判定します。成功した場合は、セッションと Cookie にユーザー ID、ユーザー名などの判断に必要な情報が書き込まれます。一定期間 (たとえば、ログイン時に 1 日から 2 週間)、さらに、Cookie に保存されたデータの json_encode を作成し、それを暗号化します。
たとえば、{"uid":1,"username":"fdipzone"} は、可逆文字列に暗号化されます。

2. ユーザーが訪問すると、次のような状況になります
1. セッションが存在するかどうかを判断します -> はい -> パス
2. セッションが存在するかどうかを判断します -> いいえ -> Cookie が存在するかどうかを判断します-> はい-> Cookie の復号化が成功したかどうかを判断します-> はい-> セッションに Cookie を書き込みます-> 合格
3. セッションが存在するかどうかを判断します-> いいえ-> Cookie が存在するかどうかを判断します-> はい-> Cookie の復号化が成功したかどうかを判断します -> いいえ - > セッションが存在するかどうかを判断します - > いいえ - >ログイン ページへ

あなたのプロセスはデータベースにクエリを行っていないように見えます。これは非常に経済的ですが、抜け穴があります:
1 アカウントが通常通り 11 時にログインしている場合、アカウントは盗まれ、パスワードは12時に変更されます。しかし、ユーザーは引き続きアカウントを使用し、ハッカーと一緒に使用することができます
2 ユーザーのパスワードが変更されたとしますが、ログアウトして再度ログインすることなくアカウントを使用し続けることができます
3 さらに重要なのは、それは制御不可能であるということです。ユーザーが 11 時にログインし、管理者は 12 時にアカウントを禁止しましたが、ログアウトして再度ログインしない限り、引き続き使用できるとします。

これが私のやり方です。
1. ユーザーはログイン後、データベースに接続し、成功したかどうかを判定します。成功した場合は、セッションと Cookie にユーザー ID、ユーザー名などの判断に必要な情報が書き込まれます。一定期間 (たとえば、ログイン時に 1 日から 2 週間)、さらに、Cookie に保存されたデータの json_encode を作成し、それを暗号化します。
たとえば、{"uid":1,"username":"fdipzone"} は、可逆文字列に暗号化されます。

2. ユーザーが訪問すると、次のような状況になります
1. セッションが存在するかどうかを判断します -> はい -> パス
2. セッションが存在するかどうかを判断します -> いいえ -> Cookie が存在するかどうかを判断します-> はい-> Cookie の復号化が成功したかどうかを判断します-> はい-> セッションに Cookie を書き込みます-> 合格
3. セッションが存在するかどうかを判断します-> いいえ-> Cookie が存在するかどうかを判断します-> はい-> Cookie の復号化が成功したかどうかを判断します -> いいえ - > セッションが存在するかどうかを判断します - > いいえ - >ログイン ページへ

あなたのプロセスはデータベースにクエリを行っていないように見えます。これは非常に経済的ですが、抜け穴があります:
1 アカウントが通常通り 11 時にログインしている場合、アカウントは盗まれ、パスワードは12時に変更されます。しかし、ユーザーは引き続きアカウントを使用し、ハッカーと一緒に使用することができます
2 ユーザーのパスワードが変更されたとしますが、ログアウトして再度ログインすることなくアカウントを使用し続けることができます
3 さらに重要なのは、それは制御不可能であるということです。ユーザーが 11 時にログインし、管理者は 12 時にアカウントを禁止しましたが、ログアウトして再度ログインしない限り、引き続き使用できるとします。




closeuser部分はログイン後に実行されると判断します。前の手順が失敗した場合、closeuser を呼び出して判断する必要がないためです。

ところで、私が見逃していた場所があります。それは、セッションの有効期限が切れると、Cookie がセッションに書き込まれるときです。この操作の時間をユーザーの最後のオンライン時間としてデータベースに記録します。前回の最終オンライン時刻が現在時刻より10分以上大きいと判断された場合は、closeuserテーブルを確認してブロックされているかどうかを判断します。ブロックされている場合は、対応する情報プロンプト ページにジャンプします。 10分ごとにデータベースをチェックするだけです。
セッションが存在するかどうかを判断する -> いいえ -> Cookie が存在するかどうかを判断する -> はい -> Cookie をセッションに書き込む ->
その後、10 分ごとに 1 回確認してください

これが私のやり方です。
1. ユーザーはログイン後、データベースに接続し、成功したかどうかを判定します。成功した場合は、セッションと Cookie にユーザー ID、ユーザー名などの判断に必要な情報が書き込まれます。一定期間 (たとえば、ログイン時に 1 日から 2 週間)、さらに、Cookie に保存されたデータの json_encode を作成し、それを暗号化します。
たとえば、{"uid":1,"username":"fdipzone"} は、可逆文字列に暗号化されます。

2. ユーザーが訪問すると、次のような状況になります
1. セッションが存在するかどうかを判断します -> はい -> パス
2. セッションが存在するかどうかを判断します -> いいえ -> Cookie が存在するかどうかを判断します-> はい-> Cookie の復号化が成功したかどうかを判断します-> はい-> セッションに Cookie を書き込みます-> 合格
3. セッションが存在するかどうかを判断します-> いいえ-> Cookie が存在するかどうかを判断します-> はい-> Cookie の復号化が成功したかどうかを判断します -> いいえ - > セッションが存在するかどうかを判断します - > いいえ - >ログイン ページへ

あなたのプロセスはデータベースにクエリを行っていないように見えます。これは非常に経済的ですが、抜け穴があります:
1 アカウントが通常通り 11 時にログインしている場合、アカウントは盗まれ、パスワードは12時に変更されます。しかし、ユーザーは引き続きアカウントを使用し、ハッカーと一緒に使用することができます
2 ユーザーのパスワードが変更されたとしますが、ログアウトして再度ログインすることなくアカウントを使用し続けることができます
3 さらに重要なのは、それは制御不可能であるということです。ユーザーが 11 時にログインし、管理者は 12 時にアカウントを禁止しましたが、ログアウトして再度ログインしない限り、引き続き使用できるとします。




実際、ユーザーがインターネット カフェなどでログインし、ログアウトするのを忘れた場合、たとえユーザーが戻ったとしても、他の人がそのインターネット デバイスを使用して自分のアカウントのコンテンツを操作できるということです。ホームにアクセスしてパスワードを変更しても、ログアウトして再度ログインしない限り役に立ちません（ブラウザプロセスのシャットダウン/再起動/完全な終了を含む）。

これが私のやり方です。
1. ユーザーはログイン後、データベースに接続し、成功したかどうかを判定します。成功した場合は、セッションと Cookie にユーザー ID、ユーザー名などの判断に必要な情報が書き込まれます。一定期間 (たとえば、ログイン時に 1 日から 2 週間)、さらに、Cookie に保存されたデータの json_encode を作成し、それを暗号化します。
たとえば、{"uid":1,"username":"fdipzone"} は、可逆文字列に暗号化されます。

2. ユーザーが訪問すると、次のような状況になります
1. セッションが存在するかどうかを判断します -> はい -> パス
2. セッションが存在するかどうかを判断します -> いいえ -> Cookie が存在するかどうかを判断します-> はい-> Cookie の復号化が成功したかどうかを判断します-> はい-> セッションに Cookie を書き込みます-> 合格
3. セッションが存在するかどうかを判断します-> いいえ-> Cookie が存在するかどうかを判断します-> はい-> Cookie の復号化が成功したかどうかを判断します -> いいえ - > セッションが存在するかどうかを判断します - > いいえ - >ログイン ページへ

あなたのプロセスはデータベースにクエリを行っていないように見えます。これは非常に経済的ですが、抜け穴があります:
1 アカウントが通常通り 11 時にログインしている場合、アカウントは盗まれ、パスワードは12時に変更されます。しかし、ユーザーは引き続きアカウントを使用し、ハッカーと一緒に使用することができます
2 ユーザーのパスワードが変更されたとしますが、ログアウトして再度ログインすることなくアカウントを使用し続けることができます
3 さらに重要なのは、それは制御不可能であるということです。ユーザーが 11 時にログインし、管理者は 12 時にアカウントを禁止しましたが、ログアウトして再度ログインしない限り、引き続き使用できるとします。




closeuser部分はログイン後に実行されると判断します。前の手順が失敗した場合、closeuser を呼び出して判断する必要がないためです。

ところで、私が見逃していた場所があります。それは、セッションの有効期限が切れると、Cookie がセッションに書き込まれるときです。この操作の時間をユーザーの最後のオンライン時間としてデータベースに記録します。前回の最終オンライン時刻が現在時刻より10分以上大きいと判断された場合は、closeuserテーブルを確認してブロックされているかどうかを判断します。ブロックされている場合は、対応する情報プロンプト ページにジャンプします。 10分ごとにデータベースをチェックするだけです。
セッションが存在するかどうかを判断する -> いいえ -> Cookie が存在するかどうかを判断する -> はい -> Cookie をセッションに書き込む ->
その後、10 分ごとに 1 回確認します


セッションを使用して情報を保存し、ブラウザを閉じると (ブラウザ プロセスを強制的に閉じることを含みます)、セッションは期限切れになりますか?

訂正。
セッションの有効期限が切れたら、セッションに Cookie を書き込みます。この場所でデータベースに接続し、ユーザーのログインが禁止されているかどうかが判断されます。
セッションには独自の有効期限があるため、各データベースチェック間の時間間隔がセッションのライフサイクルになります。

セッションが存在するかどうかを判断します -> いいえ -> Cookie が存在するかどうかを判断します -> はい -> ログインが禁止されているかどうかを確認します -> いいえ- >Cookie を書き込む セッションに入る ->

を使用してセッションが存在するかどうかを判断する ->いいえ ->Cookie が存在するかどうか判断する ->はい->Cookie の復号化が成功したかどうか判断する ->はい- >ログインが禁止されているかどうかを確認します ->はい ->ユーザーの Cookie をクリアします ->通知ページに移動

私のやり方はこうです。
1. ユーザーはログイン後、データベースに接続し、成功したかどうかを判定します。成功した場合は、セッションと Cookie にユーザー ID、ユーザー名などの判断に必要な情報が書き込まれます。一定期間 (たとえば、ログイン時に 1 日から 2 週間)、さらに、Cookie に保存されたデータの json_encode を作成し、それを暗号化します。
たとえば、{"uid":1,"username":"fdipzone"} は、可逆文字列に暗号化されます。

2. ユーザーが訪問すると、次のような状況になります
1. セッションが存在するかどうかを判断します -> はい -> パス
2. セッションが存在するかどうかを判断します -> いいえ -> Cookie が存在するかどうかを判断します-> はい-> Cookie の復号化が成功したかどうかを判断します-> はい-> セッションに Cookie を書き込みます-> 合格
3. セッションが存在するかどうかを判断します-> いいえ-> Cookie が存在するかどうかを判断します-> はい-> Cookie の復号化が成功したかどうかを判断します -> いいえ - > セッションが存在するかどうかを判断します - > いいえ - >ログイン ページへ

あなたのプロセスはデータベースにクエリを行っていないように見えます。これは非常に経済的ですが、抜け穴があります:
1 アカウントが通常通り 11 時にログインしている場合、アカウントは盗まれ、パスワードは12時に変更されます。しかし、ユーザーは引き続きアカウントを使用し、ハッカーと一緒に使用することができます
2 ユーザーのパスワードが変更されたとしますが、ログアウトして再度ログインすることなくアカウントを使用し続けることができます
3 さらに重要なのは、それは制御不可能であるということです。ユーザーが 11 時にログインし、管理者は 12 時にアカウントを禁止しましたが、ログアウトして再度ログインしない限り、引き続き使用できるとします。




closeuser部分はログイン後に実行されると判断します。前の手順が失敗した場合、closeuser を呼び出して判断する必要がないためです。

ところで、私が見逃していた場所があります。それは、セッションの有効期限が切れると、Cookie がセッションに書き込まれるときです。この操作の時間をユーザーの最後のオンライン時間としてデータベースに記録します。前回の最終オンライン時刻が現在時刻より10分以上大きいと判断された場合は、closeuserテーブルを確認してブロックされているかどうかを判断します。ブロックされている場合は、対応する情報プロンプト ページにジャンプします。 10分ごとにデータベースをチェックするだけです。
セッションが存在するかどうかを判断する -> いいえ -> Cookie が存在するかどうかを判断する -> はい -> Cookie をセッションに書き込む ->
その後、10 分ごとに 1 回チェックします

セッションを使用して情報を保存し、ブラウザを閉じると (ブラウザのプロセスを強制的に閉じることを含む)、セッションは期限切れになりますか?



はい、Cookie を決定するイベントは終了しますか?が実行されます。

訂正。

セッションの有効期限が切れたら、セッションに Cookie を書き込みます。この場所でデータベースに接続し、ユーザーのログインが禁止されているかどうかが判断されます。

セッションには独自の有効期限があるため、各データベースチェック間の時間間隔がセッションのライフサイクルになります。

セッションが存在するかどうかを判断します -> いいえ -> Cookie が存在するかどうかを判断します -> はい -> ログインが禁止されているかどうかを確認します -> いいえ- >Cookie を書き込む セッションに入る ->

を使用してセッションが存在するかどうかを判断する ->いいえ ->Cookie が存在するかどうか判断する ->はい->Cookie の復号化が成功したかどうか判断する ->はい- >ログインが禁止されているか確認 ->はい ->ユーザーの Cookie をクリア ->通知ページへジャンプ

これであれば、もう SESSION する必要はないようです。
しかし、ブラウザを閉じるとセッションが期限切れになるというのは本当に信じられないことです。 。 。

訂正。
セッションの有効期限が切れたら、セッションに Cookie を書き込みます。この場所でデータベースに接続し、ユーザーのログインが禁止されているかどうかが判断されます。
セッションには独自の有効期限があるため、各データベースチェック間の時間間隔がセッションのライフサイクルになります。

セッションが存在するかどうかを判断します -> いいえ -> Cookie が存在するかどうかを判断します -> はい -> ログインが禁止されているかどうかを確認します -> いいえ- >Cookie を書き込む セッションに入る ->

を使用してセッションが存在するかどうかを判断する ->いいえ ->Cookie が存在するかどうか判断する ->はい->Cookie の復号化が成功したかどうか判断する ->はい- > ログインが禁止されているかどうかを確認します - >はい ->ユーザーの Cookie をクリアします ->通知ページに移動

これであれば、もう SESSION する必要はないようです。
しかし、ブラウザを閉じるとセッションが期限切れになるというのは本当に信じられないことです。 。 。





セッションはセッションプロセスであり、セッションを閉じると消えるのが通常です。
セッションは実際には Cookie ですが、その存続時間は比較的短いですが、クライアントはセッション ID の Cookie 値のみを保存し、その他のコンテンツはサーバーに保存されます。ブラウジング時にセッション ID を使用します。

html5 の localStorage と sessionStorage に似ています

これが私のやり方です。
1. ユーザーはログイン後、データベースに接続し、成功したかどうかを判定します。成功した場合は、セッションと Cookie にユーザー ID、ユーザー名などの判断に必要な情報が書き込まれます。一定期間 (たとえば、ログイン時に 1 日から 2 週間)、さらに、Cookie に保存されたデータの json_encode を作成し、それを暗号化します。
たとえば、{"uid":1,"username":"fdipzone"} は、可逆文字列に暗号化されます。

2. ユーザーが訪問すると、次のような状況になります
1. セッションが存在するかどうかを判断します -> はい -> パス
2. セッションが存在するかどうかを判断します -> いいえ -> Cookie が存在するかどうかを判断します-> はい-> Cookie の復号化が成功したかどうかを判断します-> はい-> セッションに Cookie を書き込みます-> 合格
3. セッションが存在するかどうかを判断します-> いいえ-> Cookie が存在するかどうかを判断します-> はい-> Cookie の復号化が成功したかどうかを判断します -> いいえ - > セッションが存在するかどうかを判断します - > いいえ - >ログイン ページへ

あなたのプロセスはデータベースにクエリを行っていないように見えます。これは非常に経済的ですが、抜け穴があります:
1 アカウントが通常通り 11 時にログインしている場合、アカウントは盗まれ、パスワードは12時に変更されます。しかし、ユーザーは引き続きアカウントを使用し、ハッカーと一緒に使用することができます
2 ユーザーのパスワードが変更されたとしますが、ログアウトして再度ログインすることなくアカウントを使用し続けることができます
3 さらに重要なのは、それは制御不可能であるということです。ユーザーが 11 時にログインし、管理者は 12 時にアカウントを禁止しましたが、ログアウトして再度ログインしない限り、引き続き使用できるとします。




closeuser部分はログイン後に実行されると判断します。前の手順が失敗した場合、closeuser を呼び出して判断する必要がないためです。

ところで、私が見逃していた場所があります。それは、セッションの有効期限が切れると、Cookie がセッションに書き込まれるときです。この操作の時間をユーザーの最後のオンライン時間としてデータベースに記録します。前回の最終オンライン時刻が現在時刻より10分以上大きいと判断された場合は、closeuserテーブルを確認してブロックされているかどうかを判断します。ブロックされている場合は、対応する情報プロンプト ページにジャンプします。 10分ごとにデータベースをチェックするだけです。
セッションが存在するかどうかを判断する -> いいえ -> Cookie が存在するかどうかを判断する -> はい -> Cookie をセッションに書き込む ->
次に、10 分ごとに 1 回確認します

ユーザーがページを操作している場合、SESSION にはタイムアウトが設定されていますが、時間が経過すると期限切れになりますか?