これが長すぎる場合は申し訳ありません:
2つのサーバー(server_oldとserver_new)で同じサイトを実行しています。在庫を管理し、顧客に機器を貸し出すために手作業で作成したPHPとAjaxのものです。このWebサイトで紹介されているものと同様の基本的なログインシステムがあります。 PHPおよびMYSQLで安全なログインスクリプトを作成する方法 。したがって、PHPセッション変数を使用して、ログインしているかどうかを確認し、ログインしていない場合はログインページを表示します。少なくとも意図的にではなく、何分も何時間も後にあなたを追い出すようなメカニズムを実装しませんでした。
Server_oldはApache 2.4.7およびPHP 5.5.9でLinux Mint 17を実行し、server_newはApache 2.4.6およびPHP 5.4.16でRHEL 7を実行しています。
私は両方のシステムのhttdp.confとphp.iniを調べましたが、その理由はわかりません。
Server_oldのサイトにログインしているとき、私のログインは約20分間の非アクティブの間のみ有効であるようです。 gc_maxlifetimeが影響している場合、これは理にかなっています。長時間アイドル状態になってからページにアクセスしようとすると、ログインページにリダイレクトされます。これはもちろんセキュリティに良いので、苦情はありません。
次に、サイトとDBをserver_newに移行し、何時間も活動していない状態でログインしましたが、それでも問題ありません。 2時間以上経過していることはわかっていますが、3時間以上かかっているはずです。手動でログアウトすることはできますが、ログインし直すまでサイトはログインページを通過させないため、その部分は機能しています。
数分後にMintのサイトからログアウトした理由がわからず、RHELでPHPセッションが永遠に続くようです。両方のサーバーには次のものがあります。
phpinfo()は、両方のシステムで同じことを報告します。ただし、Mintではgc_probabilityが0/1000に設定されています(本質的にゴミを収集しないのですか?)が、RHELでは1/1000に設定されています。ガベージを収集せずcookie_lifetime = 0に設定すると、Mintでセッションが永遠に続くことになると思います。しかし、明らかに反対です。
両方のApacheサーバーが同じタイムアウト、キープアライブなどで設定されています。
何か案は?
ここで起こっていることは、主に異なる種類のLinux間のガベージコレクションの違いによるものです。 @Tim Fountainで前述したように、Linuxのdebianベースのフレーバーでのガベージコレクションは、cronジョブを介してガベージコレクションを実行します。セッションに関するPHPのドキュメントのチェックでは、gc_maxlifetime
で設定された時間が、データがゴミとして認識されるまでの秒数であり、潜在的にクリーンアップされていることがわかります。サーバーでガベージコレクションが定期的に実行されていない場合、これはトリガーされず、データは残ります。
一定のアイドル時間後にセッションからユーザーをログアウトする最も信頼できる方法は、time()
関数を使用してUNIXタイムスタンプであるlastAction
のようなセッション変数を追加することです。その後、リクエストが行われるたびに、最初にlastAction
タイムスタンプが特定の秒数(必要な最大アイドル時間に基づいて)よりも古いかどうかを確認し、セッションを強制終了する場合は、ログアウトコードを使用して、ユーザーをログインページにリダイレクトします。最大秒数より短い場合は、lastAction
セッション変数の値を現在のユニットのタイムスタンプでリセットして続行します。