最近のプロジェクトには比較的大きなフォームが含まれており、多くのユーザーがそれを完了するのに多大な時間を費やした後、セッションの有効期限が切れていることがわかりました。送信後にシステムが終了したため、SESSION を設定し、SESSION をオンラインに保つ方法を検討する必要があります。
セッションとは何ですか?
WIKIの説明によると、SESSIONとは、2台の通信機器間に存在する対話型の情報であり、ある時刻に確立され、一定期間が経過すると消滅するそうです。一般的なセッションには、TCP セッション、WEB セッション (HTTP セッション)、ログイン セッションなどが含まれます。
OSI モデルにおけるセッション実装のさまざまな位置に応じて、SESSION は主にいくつかのタイプに分けられます。1 つは WEB SESSION (Http SESSION) と Telnet リモート ログイン セッションです。実装にはセッション開始プロトコル (SIP) とインターネット電話通話が含まれます。TCP SESSION はトランスポート層で実装されます。
この記事では主に WEB SESSION について説明します。これには通常、クライアント SESSION と サーバー SESSION の 2 つのタイプがあります。後者は Java Beans によって提供される最も一般的なものです。
セッションって何をするの?
コンピュータ分野、特にネットワークにおいては、セッション(SESSION)が特に広く使われており、対話(Dialogue)、会話などとも呼ばれます。一般に、2 つの通信装置間で保存される状態を指し、場合によってはユーザー間でも発生します。とコンピュータ(ログインセッション)。
通常、SESSION はステートレス通信とは異なり、通信状態を保存するために使用されます。そのため、通信を行う 2 つの当事者のうち少なくとも一方が SESSION の履歴を保存する必要があります。
SESSION(WEB SESSION)はどのように実施されるのですか?
ブラウザとサーバー間で HTTP 通信が実行されると、通常、ステータスを識別するために HTTP Cookie が含まれ、ユーザーの確認情報とレベルが記録されます。
いくつかのプログラミング言語で最も一般的に使用される Http セッション トークンは、JSESSIONID (JSP)、PHPSESSID (PHP)、ASPSESSIONID (ASP)、この ID は通常、ハッシュ関数によって生成され、サーバーとクライアントが通信するときにユーザーの ID を一意に表すことができ、GET または POST パラメーターとしてクライアントに保存されます。
通常、SESSION を実装するにはサーバー側 SESSION とクライアント側 SESSION の 2 つの方法があり、どちらの方法にもそれぞれ長所と短所があります。
サーバー側 SESSION は実装が簡単で効率が高いですが、負荷分散や高可用性の要件が発生した場合の処理がより難しくなります。また、内生システムにストレージ デバイスがない場合には使用できません。負荷分散は、ファイル システムを共有するか、顧客に 1 つのサーバーのみに強制的にログインさせることで実現できますが、これでは効率が低下します。ストレージのないデバイスの場合、サーバー側の SESSION 実装は RAM を使用して解決することもできます (参考資料 6 を参照)。この方法は、クライアント接続が制限されているシステム (ルーティングまたはアクセス ポイント デバイスなど) に効果的です。
クライアント側 SESSION を使用すると、負荷分散アルゴリズムの回避など、サーバー側 SESSION のいくつかの問題を解決できますが、それ自体がいくつかの問題を引き起こすこともあります。クライアント SESSION は、Cookie と暗号化テクノロジーを使用して、異なるリクエスト間の状態を保存します。各動的ページが終了すると、現在のセッションがカウントされ、クライアントに送り返されます。リクエストが成功するたびに、サーバーにユーザーの ID を「記憶」させるために Cookie がサーバーに送信されます。クライアント SESSION の最も重要な問題はセキュリティです。Cookie がハイジャックまたは改ざんされると、ユーザーの情報のセキュリティが失われます。
PHPでSESSIONを設定するにはどうすればよいですか?
PHP 開発環境をセットアップした後、phpinfo() を通じて次のような SESSION 関連の部分を表示できます。
PHP V5.2.9 バージョンの SESSION モジュールには、合計 25 個の変数があります。その中で、日常の設定でよく使用されるものは次のとおりです:
session.cookie_lifetime SESSIONID
を保存するための Cookie の有効期限を設定します。
session.name SESSION の COOKIE 名、デフォルトは PHPSESSID
session.save_handler SESSION ストレージメソッド、デフォルトは FILE
session.save_path は、Fedora ではデフォルトで /var/lib/php/session
に保存されます
session.gc_probability
session.gc_divisor
session.gc_maxlifetime これら 3 つのオプションは、GC メカニズム
の確率を処理するために使用されます。
session.cache_limiter (nocache、プライベート、プライベート_no_expire、パブリック)
session.cache_expire これら 2 つのオプションは、SESSION ページをキャッシュするために使用されます
まずは最初の質問、つまり SESSION の有効期限が切れるまでにどのくらいの時間がかかり、どのように期限切れになるのかを考えてみましょう。 PHP プログラムで SESSION を使用する場合は、まず session_start() を参照する必要があります。この関数が実行されると、SESSION ファイルが SESSION の格納ディレクトリに生成されます (ファイル ハンドラーが使用されている場合)。同時に、参照します。サーバーは、ハッシュ化された SESSION 名を保存する PHPSESSID という名前の Cookie にアクセスします。
SESSION の有効期限は、SESSION の作成後、クライアント スクリプトが SESSION 内の変数にアクセスするたびに、ガベージ コレクション メカニズム (ガベージ コレクション) に依存します。更新されました。各訪問は、クライアントに保存されている SESSIONID に基づいて、サーバーに保存されている一意の SESSION を要求します。クライアントの Cookie の有効期限が切れると、サーバー上の SESSION ファイルはまだアクセスされていませんが、どの SESSION にアクセスするかを知ることはできません。有効期限が切れると、サーバー リソースが無駄に消費されます。
しかし同時に、ユーザーのセッションをすぐに期限切れにしたい場合は、Cookie を設定することでこれを行うことができます。 SESSION リサイクルは、ページがアクセスされるたびに実行されます。リサイクルの確率は session.gc_probability、session_gc_divisor で指定され、デフォルトは ±1/100 です。 1 に設定すると、SESSION がその有効期間を超えてアクセスされるたびに、SESSION がリサイクルされます。
2 つの要件: 1. SESSION が期限切れにならないようにするか、SESSION の有効期限を延長します。 2. SESSION をすぐに期限切れにする。
1. 特に内部アプリケーション システムや大規模なフォームがある場合、SESSION の有効期限が切れないようにして、SESSION の有効期限を延長することが非常に必要です。上司がフォームに記入するときのことを考えてください。ちょうど昼食の時間でした。彼は昼食から戻ってくるまでフォームを保管し、残りの内容を記入します。送信後に表示されるのは、通常、ログイン インターフェイスです。ユーザーエクスペリエンスを向上させたい場合は、上司のフォームが問題を引き起こすのを防ぐことが重要です。SESSION のライフサイクルを延長する必要があります。
SESSION の期限切れを防ぎ、SESSION の有効期限を延長するには、session.gc_maxlifetime を設定します。ただし、gc がリサイクルを実行する前にクライアントの Cookie が期限切れにならないようにする必要があります。 gc_maxlifetime を長く設定すると、セッションの有効期間を延長できますが、すべてのリクエストが長期間保持されるわけではないアプリケーションの場合、これは明らかにサーバー構成にとって最良の選択ではありません。
SESSION のリサイクル機構は、SESSION ファイルの最終アクセス時刻に基づいて判断され、maxlifetime を超えた場合、リサイクル確率に基づいてリサイクルされることがわかっています。したがって、SESSION に定期的にアクセスするだけで済みます。これは、ページを更新することで実現できます。これには解決策があります。
JS を介してページに定期的にアクセスします。
Iframe を使用してページを定期的に更新してください
プログラムを直接使用して HTTP リクエストを送信すると、ページに他の要素を埋め込む必要がなくなります。
以下は、ページ(大きなフォームページなど)でSESSIONを長時間維持するだけで済むように、JSを使用してSESSIONが期限切れにならないようにリクエストを送信する実装方法です。
<スクリプトタイプ="text/javascript">
関数 keepMeAlive(imgName){
myImg = document.getElementById(imgName);
If(myImg) myImg.src = myImg.src.replace(/?.*$/, '?' + Math.random());
}
window.setInterval("keepMeAlive('phpImg');", 4000);
このリンクに対するリクエストがブラウザによってキャッシュされないように、URL の後に乱数が追加されます。
2. SESSION をすぐに期限切れにする方法はたくさんあります。session_destroy() を使用することも、上記のアイデアを使用して session_destroy ページをリクエストすることもできます。
セッションは安全ですか?
PHP マニュアルには明確に記載されています: SESSION は、SESSION に保存されている情報がその作成者のみに表示されることを保証しません。
一部のリモート操作を安全に処理したい場合は、HTTPS が唯一の選択肢です。最も基本的なことは、SESSION にユーザーの情報が存在するからといって、そのユーザーは本人である必要があると考えないことです。ただし、SESSION 内の情報によりユーザー名とパスワードによって認証されているかのように錯覚します。したがって、パスワードなどを変更する必要がある場合は、ユーザーにパスワードの再入力を求めることをお勧めします。
Apache
の初期バージョンでは、PHPSESSID の保存に COOKIE を使用していませんでしたが、URL の書き換えを使用していました。つまり、各 URL の後に、どのセッションに属しているかを示す PHPSESSID=
この意味で、SESSION をあまりにも長く延長したり、SESSION をオンラインに維持したりすることは、セキュリティにとって常に良いことではありません。究極の解決策は、ユーザーがログイン後に送信してログイン ウィンドウにジャンプし、すべてのデータが残っている状態で入力ページに戻ることです。現在の Ajax を使用してこの実装を解決するのは難しくありません。現在のユーザー データは、XML であっても JSON であっても、一定の間隔で保存場所に POST されます。
サプリメント:
クライアントが JavaScript をサポートしていない場合に採用できるメソッド:
1. フローティング レイヤーを作成し、それを最上位に表示します。ユーザーが JS を無効にしない場合、フローティング レイヤーは表示されません。
2. すべての INPUT を無効に設定し、JS を使用して有効に設定します。
上記の方法はどちらも JS が無効になっているときに使用され、すべての機能が使用できなくなります。JS が無効になっているときにアプリケーションを正常に動作させる方法はさらに難しいようです。これを達成するのにかかる時間と得られる結果を比較検討する必要があります。