誰かがページをロードするたびに、データベースをチェックして、セッションがまだ有効かどうかを確認する必要があります。そのCronJobタスクで、ユーザーのPHPセッションを見つけて、$ _SESSION ['isValidSession']などの変数を変更してfalseに設定できるかどうか疑問に思っています。
関係なくこれを行う必要があります。ユーザーがページをロードすると、システムはセッションがデータベースに存在するかどうかを確認する必要があります (DB を使用していると仮定します)。
cron ジョブを 1 分ごとに実行し、5 より古いすべてのセッションを期限切れにする場合 (これはかなり過剰に思えますか? 長いページを読んでいると、サイトで 5 分、10 分、さらには 15 分も非アクティブなままになることがよくあります)、これは自動的に "セッションを無効としてマークする (実際には削除する)。
通常TIMESTAMP
、その行の最終更新時刻 (つまり、そのセッション) の列を保持し、cron ジョブはDELETE
5 分より前のタイムスタンプを持つすべての行を保持します。ページをリロードすると、システムは関連するセッション行を見つけられなくなり、セッションが期限切れになったと (正しく) 推測します。
ただし、必要なこと ( SessionID を知っているセッションの読み取り) は、cron ジョブ (PHP でジョブをコーディングできます) によってセッションを読み取ることによって、その ID を指定して既存のセッションとしてロードするか、保持されている DB 列を読み取ることによって達成できます。シリアライズされたデータを aSELECT SessionData FROM SessionTable WHERE id = 'SessionId';
でデシリアライズします。次に、膨張したオブジェクトを変更し、再シリアル化して、SQL を使用してデータベースに保存しますUPDATE
。セッションが変更されました。
ただし、これはアクティブなクライアントで同時実行性の問題を引き起こす可能性が高く、SQL で一気に実行できないことに注意してくださいUPDATE Sessions SET isInactive = 1 WHERE expiry...
。直接実行することはできません。通常、関心のある行を 1 つずつ読み取り、シリアル化を解除して保存し、PHP コードで処理する必要があります。
2 つの異なる回避策で間接的に行うことができます。
1 つは、シリアル化されていないデータを使用するようにセッション コードを変更することです。これは保守性とパフォーマンスに影響を与えます (セッションに何かを「単に追加」することはできません。そのための列を作成する必要があります)。
2: シリアル化された形式では、「0」と「1」の長さが同じであるという事実を利用します。つまり、isValidSession
(14 文字の名前) を含むシリアル化されたセッションには、テキストが含まれます。
...{s:14:"isValidSession";b:1;}...
そして、その文字列を で変更できる{s:14:"isValidSession";b:0;}
ため、 にisValidSession
なりFalse
ます。これは特に良い習慣ではありません.システムの内部をいじっています. もちろん、PHP のシリアル化されたデータ構文がすぐに変更されるとは誰も思っていません (...またはそうですか?)。