PHP のデフォルトのセッションタイムアウトは 30 分ですが、30 分前に自動的にタイムアウトになる場合があり、これにより多くの操作に不都合が生じます。30 分のタイムアウトを解決する方法を見てみましょう。
最初の回答
そして、最も一般的な答えは次のとおりです: セッションの有効期限を設定します。これは session.gc_maxlifetime です。この答えは次の理由により正しくありません。
1. まず、この PHP はセッションの gc を実行するために一定の確率、つまり session.gc_probability と session.gc_divisor を使用します (詳細については、セッション Gc の小さな確率に関する注意事項を参照してください)デフォルト値はそれぞれ 1 と 100 です。これは、セッションの開始時に PHP がセッション gc を実行する可能性が 1% であることを意味します。セッションが 30 分で期限切れになるという保証はありません。2. 高確率のクリーンアップ機会を設定するのはどうでしょうか? それでも不適切なのは、PHP が統計セッション ファイルの有効期限が切れているかどうかを判断するためです。 , PHP は、セッションに関連するセッション変数を保存するために " "A" ファイルを使用します。 5 分前に a=1 でセッション変数を設定し、5 分後に b=2 で Seesion 変数を設定したとします。すると、この変更時刻がセッションファイルは瞬間bの時間を追加すると、30分でaがクリアできなくなります
下記の3つ目の理由もあります。3. PHP (例として Linux) は、セッションのデフォルトの保存ディレクトリとして /tmp を使用し、マニュアルにも次のような記述があります。
注: 異なるスクリプトの session.gc_maxlifetime 値が異なるが、セッション データを保存する場所が同じである場合、値が最も小さいスクリプトがデータをクリーンアップします。この場合、このディレクティブを session.save_path と一緒に使用します。
言い換えると、独自の独立した save_path を指定していない 2 つのアプリケーションがある場合、1 つは有効期限を 2 分に設定し (A と仮定します)、もう 1 つは有効期限を 30 分に設定します (B と仮定します)。 A のセッションごとに gc が実行されていると、アプリケーション B に属するセッション ファイルも同時に削除されます。
つまり、最初の答えは「完全に厳密に」正しいわけではありません。
2番目の答え
もう 1 つの一般的な答えは、セッション ID のキャリアと Cookie の有効期限 (session.cookie_lifetime) を設定するというものです。この答えも、次の理由により不正確です。
この有効期限は単なる Cookie の有効期限です。つまり、セッションの有効期限はサーバーの有効期限ですが、Cookie の有効期限はクライアント (ブラウザ) によって保証されるだけです。標準ブラウザの有効期限が切れると、この Cookie (セッション ID を含む) は送信されなくなりますが、リクエストを作成する場合は、このセッション ID の値を引き続き使用できます。
4番目の答え
もちろん、面接はあなたの考えを徹底的に試すためのものではありませんが、その過程でこれらの落とし穴を指摘しますので、一般的に言えば、質問の意味に合ったアプローチは次のとおりです。
2. 各セッション値にタイムスタンプを追加します。
3. 各訪問の前にタイムスタンプを決定します。
海外のウェブサイトは session.gc_maxlifetime を参照します
session.gc_maxlifetime は、データが「ガベージ」として認識され、セッションの開始中にクリーンアップされる可能性があるまでの秒数を指定します (session.gc_probability と session.gc_divisor に応じて)。 注:
異なるスクリプトの session.gc_maxlifetime の値が異なるが、セッション データを保存する場所が同じである場合、最小値を持つスクリプトがデータをクリーンアップします。この場合、このディレクティブを session.save_path.
と一緒に使用します。 注: デフォルトのファイルベースのセッション ハンドラーを使用している場合、ファイル システムはアクセス タイム (atime) を追跡する必要があるため、セッションが行き詰まった場合にガベージ コレクションを処理する別の方法を考え出す必要があります。 atime 追跡が利用できない FAT ファイルシステムやその他のファイルシステムでは、PHP 4.2.3 以降、atime の代わりに mtime (変更された日付) が使用されるため、atime 追跡が利用できないファイルシステムでは問題は発生しません。
session.referer_check 文字列
session.referer_check には、各 HTTP リファラーをチェックする部分文字列が含まれています。リファラーがクライアントによって送信され、サブストリングが見つからなかった場合、埋め込まれたセッション ID は無効としてマークされます。デフォルトは空の文字列です。
session.entropy_file 文字列
session.entropy_file は、セッション ID 作成プロセスで追加のエントロピー ソースとして使用される外部リソース (ファイル) へのパスを指定します。例としては、多くの Unix システムで使用できる /dev/random または /dev/urandom があります。この機能は、PHP 5.3.3 以降の Windows でサポートされています。 session.entropy_length をゼロ以外の値に設定すると、PHP は Windows Random API をエントロピー ソースとして使用します。
session.entropy_length 整数
session.entropy_length は、上で指定したファイルから読み取られるバイト数を指定します。デフォルトは 0 (無効) です。
session.use_cookies ブール値
PHP 原理のセッション Gc の小さな通知
如果在ubuntu/Debian下、aptインストール的PHP採用、那么使用Session的時候、就可能会有小概率遇到这个示唆。
PHP 通知: session_start(): ps_files_cleanup_dir:opendir(/var/lib/php5) が失敗しました: 権限が拒否されました (13)
/home/laruence/www/htdocs/index.php の 22 行目
これは、PHP では、セッションの保存ハンドラーとして file_handler を使用した場合、ほぼ次の session_start の時点でセッションの Gc が実行されるためです。
http://www.bkjia.com/PHPjc/632202.htmlwww.bkjia.com