PHP で SESSION を維持する方法とそれによって生じる考え
最近のプロジェクトには比較的大きなフォームが含まれており、多くのユーザーがそれを完了するのに多大な時間を費やした後、セッションの有効期限が切れていることがわかりました。送信後にシステムが終了したため、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 が無効になっているときにアプリケーションを正常に動作させる方法はさらに難しいようです。これを達成するのにかかる時間と得られる結果を比較検討する必要があります。

ホットAIツール

Undresser.AI Undress
リアルなヌード写真を作成する AI 搭載アプリ

AI Clothes Remover
写真から衣服を削除するオンライン AI ツール。

Undress AI Tool
脱衣画像を無料で

Clothoff.io
AI衣類リムーバー

Video Face Swap
完全無料の AI 顔交換ツールを使用して、あらゆるビデオの顔を簡単に交換できます。

人気の記事

ホットツール

メモ帳++7.3.1
使いやすく無料のコードエディター

SublimeText3 中国語版
中国語版、とても使いやすい

ゼンドスタジオ 13.0.1
強力な PHP 統合開発環境

ドリームウィーバー CS6
ビジュアル Web 開発ツール

SublimeText3 Mac版
神レベルのコード編集ソフト(SublimeText3)

ホットトピック











Springboot プロジェクトの本番環境のセッションアウト タイムアウトで問題が見つかりました。問題の説明は次のとおりです: テスト環境では、application.yaml を変更することでセッションアウトが構成されていました。別の時間を設定してセッションアウト構成を確認した後、有効期限がリリース時に直接 8 時間に設定され、運用環境に到着しました。しかし、正午にお客様から、プロジェクトの有効期限が短く設定されており、30分操作がないとセッションが期限切れになり、再度ログインが必要になるというフィードバックをいただきました。開発環境の扱いの問題を解決します。springboot プロジェクトには Tomcat が組み込まれているため、プロジェクト内の application.yaml で設定されたセッションアウトが有効になります。本番環境: 本番環境リリースは

セッション障害は通常、セッションの有効期間の期限切れまたはサーバーのシャットダウンによって発生します。解決策: 1. セッションの有効期間を延長する; 2. 永続ストレージを使用する; 3. Cookie を使用する; 4. セッションを非同期的に更新する; 5. セッション管理ミドルウェアを使用する。

更新後に PHP セッションが消える問題の解決策: 1. 「session_start();」を通じてセッションを開きます; 2. すべてのパブリック設定を PHP ファイルに書き込みます; 3. 変数名は配列の添字と同じにすることはできません。 4. phpinfoでセッションデータの保存パスを確認し、ファイルディレクトリ内のsessioが正常に保存されているか確認してください。

PHPSession のクロスドメイン問題の解決策 フロントエンドとバックエンドの分離の開発では、クロスドメイン要求が標準になっています。クロスドメインの問題に対処するときは、通常、セッションの使用と管理が必要になります。ただし、ブラウザーのオリジンポリシーの制限により、デフォルトではセッションをドメイン間で共有できません。この問題を解決するには、いくつかの技術と方法を使用して、セッションのクロスドメイン共有を実現する必要があります。 1. ドメイン間でセッションを共有するための Cookie の最も一般的な使用法

セッション PHP のデフォルトの有効期限は 1440 秒、つまり 24 分です。つまり、クライアントが 24 分を超えて更新されない場合、現在のセッションは期限切れになります。ユーザーがブラウザを閉じると、セッションは終了し、セッションは存在しなくなります。

問題: 今日、プロジェクトで設定タイムアウトの問題が発生し、SpringBoot2 の application.properties への変更が反映されませんでした。解決策:server.* プロパティは、SpringBoot によって使用される埋め込みコンテナーを制御するために使用されます。 SpringBoot は、ServletWebServerFactory インスタンスの 1 つを使用してサーブレット コンテナのインスタンスを作成します。これらのクラスは、server.* プロパティを使用して、制御されるサーブレット コンテナ (tomcat、jetty など) を構成します。アプリケーションが war ファイルとして Tomcat インスタンスにデプロイされる場合、server.* プロパティは適用されません。それらは当てはまりませんが、

1. セッションに基づく SMS ログインの実装 1.1 SMS ログインのフローチャート 1.2 SMS 検証コード送信の実装 フロントエンド リクエストの説明: リクエスト メソッドの説明 POST リクエスト パス /user/code リクエスト パラメータ 電話 (電話番号) 戻り値 バックエンド インターフェイスなし実装: @Slf4j@ ServicepublicclassUserServiceImplextendsServiceImplimplementsIUserService{@OverridepublicResultsendCode(Stringphone,HttpSessionsession){//1。次の場合は携帯電話番号を確認します。

JavaScriptCookies JavaScript Cookie の使用は、設定、購入、手数料、その他の情報を記憶および追跡する最も効果的な方法です。訪問者のエクスペリエンスを向上させるために必要な情報やウェブサイトの統計。 PHPCookieCookie は、クライアント コンピューターに保存され、追跡目的で保持されるテキスト ファイルです。 PHP は HTTP Cookie を透過的にサポートします。 JavaScript Cookie はどのように機能しますか?サーバーは、訪問者のブラウザに Cookie の形式でデータを送信します。ブラウザは Cookie を受け入れることができます。存在する場合、それは訪問者のハードドライブにプレーンテキストレコードとして保存されます。さて、訪問者がサイト上の別のページに到達すると、
