[ターン]セッション詳細説明

まず、セッションという用語
私の経験では、セッションという言葉はトランザクションほど酷評されています。興味深いことに、トランザクションとセッションの意味は同じです。

セッション、中国語はしばしば会話として翻訳され、その元の意味は、セッションと呼ばれる一連のプロセスの途中で電話を拾う電話などの一連のエンドツーエンドアクション/メッセージを指します。 ときには、「ブラウザセッション中の...」という言葉を見ることができます。ここでは、セッションという言葉は、ブラウザウィンドウを開いて期間を閉じるまでの意味です。 最も混乱しやすいのは、「ユーザ(クライアント)による会話中」というフレーズであり、ユーザによる一連の動作(一般に、購入したアイテムへのログインなどの特定の目的に関連する一連の動作このようなオンラインショッピングプロセスをチェックするには、トランザクションとも呼ばれることもありますが、接続を参照する場合もありますが、それは①の意味を意味する場合がありますが、その違いはコンテキスト②からのみ推測できます。

しかし、セッションという用語がネットワークプロトコルに関連付けられている場合、「接続指向」および/または「キープアライブ」という2つの意味を意味することが多い。「接続指向」とは、通信の両方の当事者が、これに対し、手紙を書くときに相手先のアドレスが正しいかどうかを確認することができず、通信路が確立していない可能性がありますしかし、送付者にとって、コミュニケーションは既に始まっています。 "保持状態"とは、通信相手が一連のメッセージに関連付けられ、メッセージが相互に依存することができることを指します。例えば、ウェイターが古い顧客の再訪問を認識し、顧客がまだ1ドル。 このカテゴリの例は、「TCPセッション」または「POP3セッション」です。

Webサーバーが盛んになるまでに、Web開発のコンテキストでのセッションのセマンティクスには、クライアントとサーバーの間の状態を維持するために使用される一種のソリューションを意味する新しい拡張がありました。 セッションは、このソリューションのストレージ構造を参照するために使用されることもあります(「セッション中にxxxを保存する」など)。 ウェブ開発のための様々な言語がこの解決策のある程度のサポートを提供するので、セッションはまた、特定の言語の文脈における言語の解決策Javaで提供されるJavax.servlet.http.HttpSessionはセッション⑥と呼ばれます。

この混乱の観点からは、この記事で言葉のセッションの使用は、文脈に応じて異なる意味を持つ、不変であり、区別するように注意してください。
この記事では、意味を表現するために中国語の "ブラウザセッション"を使用する①、意味を表現するために "セッションメカニズム"を使用する⑤、意味を表現するために "セッション"、意味を表現するために特定の "HttpSession"を使用する⑥

第二に、HTTPプロトコルと状態を維持する
HTTPプロトコル自体はステートレスです。これはHTTPプロトコルの本来の目的と一致しており、クライアントは単にサーバー要求にいくつかのファイルをダウンロードしますが、クライアントもサーバーも、毎回互いの過去の動作を記録する必要はありません要求は、顧客と自動販売機または通常(非会員)のハイパーマーケットとの関係のように、すべて独立しています。

しかし、スマート(または貪欲)の人々は、ケーブルオンデマンドと同じように、生成する動的なオンデマンド情報の一部を提供できるようになると、すぐに役立ちます。 一方、この要求によって、フォーム、スクリプト、DOMなどのクライアント側の動作を徐々にHTMLに追加する一方で、動的なクライアント要求に応じてCGI仕様がサーバー側に表示され、トランスポートベクターとしてのHTTPアップロードによってファイルアップロード、これらの特徴はクッキーです。 クッキーの役割は、努力によってなされたHTTPプロトコルのステートレスな欠陥に対処することです。 後で出現したセッションメカニズムは、クライアントとサーバーの間で状態を維持するもう1つの解決策でした。

クッキーとセッションメカニズムの違いと関係について、いくつかの例を使って説明しましょう。 私が頻繁に行ったコーヒーショップでは、無料でコーヒーを飲むために5カップのコーヒーを持っていましたが、一度に5カップのコーヒーを飲む可能性は非常に低く、特定の顧客の消費を記録する方法はありました。 実際には以下のオプションよりも小さくなると想像してください:
1、店員は非常に強力な、顧客がコーヒーショップに入っている限り、それを扱う方法を知っている店員は、各顧客の消費の数を覚えていることができます。 この練習は、国家を支持する合意そのものです。
2、顧客にカードを発行し、上記の記録消費量、通常は有効期間があります。 購入ごとに、顧客がカードを提示する場合、購入は前または後の購入にリンクされる。 これはクライアント側で行われます。
3、どのような情報が記録されていないカード番号に加えて、会員カードを発行した顧客は、カードを生産するために顧客は、店員のレコードで見つかった店員は、レコードに対応するいくつかの消費者情報。 この方法は、サーバーの状態を維持することです。

HTTPプロトコルはステートレスなので、考慮しないとステートフルにしたくないので、後者の2つのプログラムは現実的な選択になっています。 具体的には、クッキーメカニズムは、クライアントのプログラムの状態を維持するために使用され、セッションメカニズムは、サーバーのプログラムの状態を維持するために使用されます。 同時に、サーバー側の永続性スキームが使用されているためにクライアントも識別子を保存する必要があるため、セッションメカニズムがIDを保存するためにCookieメカニズムを使用する必要があることがわかります。

第三に、クッキーメカニズムを理解する
クッキーメカニズムの基本原理は上記の例のように簡単ですが、「会員カード」の配布方法、「会員カード」の記載方法、および「会員カード」の使用方法については、いくつかの問題点があります。

正統性のあるCookieの配布は、HTTPプロトコルを拡張することによって実現されます。サーバーはHTTP応答ヘッダーに特別な行を追加して、ブラウザが指示どおりにCookieを生成するように促します。 ただし、JavaScriptやVBScriptなどの純粋なクライアントサイドスクリプトでもCookieを生成できます。

バックグラウンドで特定の原則に従ってブラウザによるクッキーの使用が自動的にサーバーに送信されます。 ブラウザは保存されているすべてのCookieをチェックします。要求されるリソースの場所以上のスコープでCookieが宣言された場合、そのCookieはHTTP要求ヘッダーに追加され、リソースを要求してサーバーに送信されます。 McDonaldの会員カードはMcDonaldの店でのみ生産することができます。支店でも会員カードを発行した場合は、McDonaldの会員カードを作成するだけでなく、店のメンバーカード。

クッキーの内容には、名前、値、有効期限、パス、およびドメインが含まれます。
Google.comなどのドメインを指定できるドメインは、Procter&Gambleなどのメインストアのサインと同じですが、 http://www.google.com/またはfroogle.googleなどのドメイン固有のマシンを指定することもできます。 com、あなたは喜ぶことを使うことができます。
パスの後に/または/ fooなどのドメイン名のURLパスが続き、Rejoiceカウンタと比較することができます。
パスとドメインの組み合わせがクッキーの範囲を構成します。
有効期限を設定しないと、ブラウザセッション中にこのCookieの存続期間があることを意味します。ブラウザウィンドウが閉じている間は、Cookieは消えます。 ブラウザセッションが存続するこのクッキーをセッションクッキーといいます。 セッションクッキーは一般的にハードディスクに保存されずにメモリに保存されますが、この動作は規制されていません。 有効期限を設定すると、ブラウザはCookieをハードディスクに保存し、ブラウザを再度開いたり閉じたりします。これらのCookieは設定された有効期限まで有効です。

ハードドライブに保存されているCookieは、2つのIEウィンドウなど、異なるブラウザプロセス間で共有できます。 メモリに保存されているCookieの場合、ブラウザによって処理方法が異なります。 IEの場合、開いているウィンドウでCtrl + N(またはファイルメニュー)で開いたウィンドウは元のウィンドウと共有できますが、開いているウィンドウのメモリクッキーは共有できません。 Firefox0.8では、すべてのプロセスとタブで同じCookieを共有できます。 一般に、javascript window.openで開いたウィンドウは、メモリクッキーを元のウィンドウと共有します。 ブラウザによるこの種のブラウザのみのクッキーのクッキーの却下は、しばしばセッション機構を使用するウェブアプリケーション開発者に重大な問題を引き起こしている。

次に、goolge cookieのレスポンスヘッダーの例を示します
HTTP / 1.1 302が見つかりました
場所: http : //www.google.com/intl/ja/
設定Cookie:PREF = ID = 0565f77e132de138:NW = 1:TM = 1098082649:LM = 1098082649:S = KaeaCFPo49RiA_d8; expires = 2038年1月19日19:14:07 GMT; path = /; domain = .google .com
Content-Type:text / html

これはHTTPLook、HTTP Snifferソフトウェアを使用してキャプチャされたHTTPトラフィックレコードの一部です

ブラウザはgoolgeのリソースに再びアクセスするときにクッキーを自動的に送ります

Firefoxを使用すると、既存のCookieの値を簡単に確認できます。FirefoxでHTTPLookを使用すると、Cookieの仕組みを簡単に理解できます。

IEは、クッキーを受け入れる前に尋ねるように設定することもできます

これはクッキーを要求するダイアログです。

第四に、セッションメカニズムを理解する
セッションメカニズムはサーバー側のメカニズムであり、サーバーはハッシュテーブルと同様の構造を使用します(またはハッシュテーブルを使用して)情報を保存します。

プログラムがクライアントの要求に対してセッションを作成する必要がある場合、サーバーは最初に、クライアントの要求にセッションIDが含まれているかどうかをチェックしますクライアント要求にセッションIDが含まれていない場合は、使用されていないセッションを取得するためのセッションIDに基づいてサーバーを作成します(取得されない場合は新規作成できます)。このクライアント用のセッションを作成し、関連付けられたセッションID、セッションID値は複製されず、パターンを模倣するために簡単に見つけられない文字列でなければならず、セッションIDはこの応答に保存するためにクライアントに返されます。

このセッションIDを保存する方法は、Cookieを使用することができます。そのため、インタラクティブなプロセスでは、ブラウザはルールに従って自動的にこのロゴをサーバーに再生できます。 一般に、このクッキーの名前はSEEESIONIDに似ています。 WebアプリケーションクッキーJSessionID = ByOK3vjFD75aPnrF7C2HmdnV6QZcEbzWoWiBYEnLerjQ99zWpBng!-145788764のために生成されたweblogicなどの名前はJSESSIONIDです。

Cookieは人為的に禁止されている可能性があるため、Cookieが無効になっているときにセッションIDをサーバーに返す他のメカニズムが必要です。 URL書き換えと呼ばれることの多い手法の1つは、 http://という形でURLパスとして追加情報を追加する2つの追加メソッドを使用して、URLパスにセッションIDを直接追加することです../xxx; jsessionid = ByOK3vjFD75aPnrF7C2HmdnV6QZcEbzWoWiBYEnLerjQ99zWpBng!-145788764
もう1つはURLの後にクエリー文字列としてhttp://...../xxxの形式で追加されます。Jsessionid = ByOK3vjFD75aPnrF7C2HmdnV6QZcEbzWoWiBYEnLerjQ99zWpBng!-145788764
ユーザーのための2つの方法は違いはありませんが、最初の方法を扱うさまざまな方法の解決のサーバーは、セッションID情報と通常のプログラムパラメータを区別するのにも役立ちます。
相互作用を通じて状態を維持するには、各クライアントがパスを要求した後でこのセッションIDを含める必要があります。

別の手法は、フォーム非表示フィールドと呼ばれます。 サーバーは自動的にフォームを変更し、フォームがサブミットされたときにセッションIDをサーバーに戻すための隠しフィールドを追加します。 たとえば、次の形式
<form name = "testform" action = "/ xxx">
<input type = "text">
</ form>
クライアントに渡される前に書き換えられます。
<form name = "testform" action = "/ xxx">
<input type = "hidden" name = "jsessionid" value = "ByOK3vjFD75aPnrF7C2HmdnV6QZcEbzWoWiBYEnLerjQ99zWpBng!-145788764">
<input type = "text">
</ form>
この技術は現在はあまり使用されていません。著者は、このテクノロジの使用について、非常に古いiPlanet6(SunONEアプリケーションサーバーの前身)と接触しています。
実際には、この手法は単にアクションのURL書き換えで置き換えることができます。

セッションの仕組みについて話すとき、私はしばしばこのような誤解を聞いています。「ブラウザーが閉じられていれば、セッションは消えてしまいます。 実際には、顧客のイニシアチブがカードを保存する場合を除き、メンバーシップカードの例を想像することができます。そうでなければ、ストアは顧客情報を簡単に削除しません。 プログラムがサーバーにセッションを削除するように通知しない限り、セッションは同じです。それ以外の場合、サーバーは常に保持されます。プログラムは通常、セッションの削除指示が発行されるとユーザーログオフされます。 しかし、ブラウザはシャットダウンする前にサーバに積極的に通知することはありませんので、サーバはブラウザがシャットダウンされたことを知る機会がありません。このような錯覚の理由は、ほとんどのセッションメカニズムがセッションCookieを使用してセッションIDセッションIDが消えた後にブラウザを閉じると、サーバは再び元のセッションを見つけることができなくなります。 サーバーがクッキーをハードディスクに保存するか、ブラウザーから送信されたHTTPリクエストヘッダーを書き換えるために何らかの手段を使用すると、元のセッションIDがサーバーに送信され、ブラウザーが元のセッションを見つけることができます。

それは正確にブラウザの閉鎖は、セッション時間の使用の最後のセッションからのクライアントが有効期限を超えて、サーバーがクライアントが活動を停止していると考えることができるときに、サーバーがseesionの有効期限を設定するために強制的に、記憶領域を節約するためにセッションを削除します。

第5に、javax.servlet.http.HttpSessionを理解する
HttpSessionのJavaプラットフォームは、仕様をサポートするだけでなく、各Webアプリケーションサーバープロバイダーに固有のインターフェイスであるため、セッションメカニズム上で規範を達成するために、ニュアンスで指定されたいくつかのマイナーな標準が存在します。 ここでは、BEAのWeblogic Server8.1を例として使用します。

まず、Weblogic Serverは、Cookieを使用したスイッチオプション、URL書き換えを使用するスイッチオプション、セッション永続性設定、セッション満了時間設定など、HttpSessionの実装を制御するための一連のパラメータを提供します。 Cookieの名前、パス、ドメイン、Cookieの生存時間などの設定の種類。

通常の状況では、セッションはメモリに保存されます。サーバープロセスが停止または再開されると、メモリ内のセッションは空になります。セッション持続機能を設定すると、サーバーはセッションをハードディスクに保存し、サーバープロセスが再起動されるか、情報を再び使用できるようになると、Weblogic Serverはファイル、データベース、クライアントのクッキーの保存とコピーを含む永続性メソッドをサポートします。

厳密に言えば、セッションは実際にメモリに格納されるため、レプリケーションは永続的な保存ではありませんが、同じ情報が各クラスタ内のサーバープロセスにコピーされるため、サーバープロセスが停止しても他のプロセスセッションを開始する。

Cookie有効期間設定は、ブラウザが生成したCookieがセッションCookieであるかどうかに影響します。 デフォルトでは、セッションCookieが使用されます。 私たちが第4章で述べた誤解をテストするのに興味があります。

クッキーへのパスは、Webアプリケーションにとって非常に重要なオプションです.WebLogic Serverのこのオプションのデフォルト処理により、他のサーバーと大きく異なることになります。 後で説明します。

セッション参照の設定[5] http://e-docs.bea.com/wls/docs70/webapp/weblogic_xml.html#1036869

6、HttpSessionのよくある質問(このセクションではセッション⑤と⑥の意味を混在させています)

1、セッションが作成されている場合一般的な誤解は、クライアントアクセスがあるときにセッションが作成されるということですが、実際にはサーバーサイドプログラムがHttpServletRequest.getSession(true)を呼び出すまでこのステートメントが作成されるまで、 JSPは<%@ page session = "false"%>の使用を表示しません。セッションを閉じると、サーブレットにコンパイルされたJSPファイルに自動的にそのようなステートメントが追加されます。HttpSession session = HttpServletRequest.getSession(true);これはJSP非表示ですセッションオブジェクトの起源を含む。

セッションはメモリーリソースを消費するため、セッションを使用する予定がない場合は、すべてのJSPでクローズする必要があります。

2、セッションが削除されたとき上記の説明を合成し、次のような状況でセッションが削除された場合a)プログラムがHttpSession.invalidate()を呼び出した場合b)クライアントがセッションID間隔を受信した最後の時刻Setまたはc。サーバープロセスが停止している(非永続セッション)

3、ブラウザを閉じたときにセッションを削除する方法
厳密に言えば、これを行うことはできません。 これを行う1つの方法は、すべてのクライアントページでjavascriptコードwindow.oncoloseを使用してブラウザのクローズアクションを監視し、サーバーにセッションを削除する要求を送信することです。 しかし、ブラウザーのクラッシュや強制的な殺人に対するこれらの従来とは違ったアプローチは、依然として手の届かないものです。

4、HttpSessionListenerは、セッションを監視してイベントを作成および破棄するようなリスナーを作成する方法の問題です。このようなイベントが発生した場合、作業を行うことができます。 セッションの作成と破棄のアクションはリスナーをトリガーし、リバースはトリガーしないことに注意してください。 HttpSessionに関連する同様のリスナーは、HttpSessionBindingListener、HttpSessionActivationListener、およびHttpSessionAttributeListenerです。

5、セッションオブジェクトに格納されている必要がありますシリアライズ可能でなければなりません。 オブジェクトがクラスターにコピーされるか、永続化されるか、または必要であれば、サーバーが一時的にメモリーからセッションをスワップできるように、オブジェクトを直列化する必要があります。 Weblogic Serverセッションで直列化不可能なオブジェクトを配置すると、コンソールに警告が表示されます。 私が使用したiPlanetのバージョンの1つセッションにシリアル化できないオブジェクトがある場合、セッションが破棄されたときに例外が発生します。これは異常です。

6、どのように正しくクライアントの可能性をハイパーリンクを含むすべてのURLのURLの書き換えのためのクッキーの使用を禁止するために対処し、URLをリダイレクト、特定の練習[6]を参照してください、
http://e-docs.bea.com/wls/docs70/webapp/sessions.html#100770

7、アプリケーションをアクセスする2つのブラウザのウィンドウを開くと、同じセッションまたは別のセッションを使用します
クッキーの議論の3番目のセクションを参照してください、セッションはIDが認識しない人を認識するので、異なるブラウザ、さまざまなクッキーのストレージメソッドとウィンドウを開くためのさまざまな方法は、この質問への答えに影響を与えます。

8、どのように2つのブラウザのウィンドウの操作セッションの混乱を開くことからユーザーを防ぐためにこの問題は、複数回送信されたフォームを防止すると、あなたは解決するためにクライアントのトークンを設定することができます。 セッションに格納されている間に別のIDがクライアントに返されるたびにサーバーで生成され、クライアントはフォームをサーバーIDに返す必要があります。プログラムは最初にIDを返し、セッションの値を保存します。一致しない場合、この操作は以前に実行依頼されています。 プレゼンテーションモードの「J2EEコアモデル」を参照してください。 注意してください、メインウィンドウが動作しない場合は、それはwindow.openを変更する操作を行うためにウィンドウを開くことをお勧めしますので、あなたができるように、javascript window.openのウィンドウを開くには、一般的にIDを設定しないでください。設定しないでください。

9、Weblogic Serverのセッションの値をsession.setValueを再呼び出しするように変更する
このアクションは、主にクラスタ環境のプロンプトでWeblogic Serverのセッション値が変更された場合に実行されます。新しいセッション値を他のサーバープロセスにコピーする必要があります。

10、セッションが消えた理由通常のセッションの障害要因から除外され、iPlanet6SP1のSolarisバージョンでも発生したパッチがいくつかあるにもかかわらず、サーバ自体の可能性は最小限に抑えられるべきであり、ブラウザプラグインの可能性私は3721プラグインに起因する問題にも遭遇しました;理論的には、クッキー処理におけるファイアウォールまたはプロキシサーバーも問題になる可能性があります。
この問題の原因のほとんどはプログラムエラーです。最も一般的なのは、あるアプリケーションで別のアプリケーションを訪れることです。 この問題については、次のセクションで説明します。

7つのアプリケーション間セッションの共有

大規模なプロジェクトがいくつかの小規模のプロジェクト開発に分割され、互いに干渉し合うように、小規模のプロジェクトごとに別々のWebアプリケーション開発を必要とするケースがよくありますが、結局のところ、いくつかの情報を共有したり、セッションを使用してSSO(シングルサインオン)を達成したり、セッションにログインユーザー情報を保存したりする場合、アプリケーションが互いのセッションにアクセスできるというのが最も自然な要件です。

しかし、サーブレット仕様によれば、セッションの範囲は現在のアプリケーションに限定されるだけで、異なるアプリケーションはお互いのセッションにアクセスできません。 実際には各アプリケーションサーバーは実際にこの仕様に従いますが、実装の詳細が異なる可能性があるため、アプリケーション間のセッション共有を処理する方法が異なります。

Tomcatの視点で設定されたCookieパスからWebアプリケーション間のTomcatセッション分離の方法を最初に見て、異なるアプリケーションのCookieパスが異なるため、異なるアプリケーションセッションID異なっているので、同じブラウザウィンドウで異なるアプリケーションにアクセスしている場合でも、サーバーに送信されるセッションIDは異なる可能性があります。

この特徴によれば、Tomcatはセッションのメモリ構造に次のように推測することができます。

私はiPlanetも同じように使いましたが、SunONEとiPlanetの間に大きな違いはないと推定されています。 サーバーへのこのアプローチでは、アイデアは解決するのが非常に簡単ですが、実際の実装は難しくありません。 すべてのアプリケーションがセッションIDを共有するようにするか、アプリケーションに別のアプリケーションのセッションIDを渡させます。

iPlanetでセッションIDを共有する方法は非常に簡単です。これは、各アプリケーションのCookieパスを/に設定することです(実際には/ NASAppである必要があります。これはアプリケーションのrootと同等です)。
<セッション情報>
<path> / NASApp </ path>
</ session-info>

共有セッションの操作は、セッション属性名の前にアプリケーションの接頭辞を付けたり、setAttribute( "name"、 "neo")をsetAttribute( "app1.name")にするなどのプログラミング規則に従う必要があります。 "neo")を使用して名前空間の競合を防ぎ、相互のカバレッジをもたらします。

Tomcatでは、そのような便利な選択肢はありません。 Tomcatバージョン3では、セッションを共有する手段もあります。 バージョン4以降のTomcatの場合、著者は簡単な解決策を見つけ出していません。 ドキュメント、データベース、JMSまたはクライアントクッキー、URLパラメータまたは隠しフィールドなどの第三者権限を使用した場合のみ。

Weblogic Serverがどのようにセッションを処理するかを見てみましょう。

スクリーンショットから、すべてのアプリケーションのWeblogic Serverがクッキーパスを設定する/と表示されます。これは、デフォルトでWeblogic Serverをセッションで共有できることを意味しますか? ただし、小さなアプリケーションでは、異なるアプリケーションが同じセッションを使用しても、各アプリケーションは設定した属性だけにアクセスできます。 これは、Weblogic Serverセッションのメモリ構造が次のようになっていることを示しています

このような構造のために、セッション共有の問題を解決するためのセッションメカニズム自体は不可能であるべきである。 ファイル、データベース、JMSまたはクライアントのCookie、URLパラメータ、またはフィールドの非表示などの第三者の力に頼ることに加えて、アプリケーションセッションをServletContextに配置するより便利な方法があります。アプリケーションは、ServletContextから前のアプリケーションへの参照を取得できます。 サンプルコードは以下の通りです。

アプリケーションA.
context.setAttribute( "appA"、session);

アプリケーションB.
contextA = context.getContext( "/ appA");
HttpSession sessionA =(HttpSession)contextA.getAttribute( "appA");

Weblogic Server 8.1で行われている、context.getContext( "/ appA");用のServletContextのJavaDocに基づいてアプリケーションサーバーを保護することができるため、この使用法は移植性がありません。

では、なぜWeblogic ServerはすべてのアプリケーションのCookieパスを/に設定するのですか? 元はSSO用で、このセッションを共有するすべてのアプリケーションが認証情報を共有できます。 シンプルな実験では、最初にログインしたアプリケーションのweblogic.xml記述子を変更し、クッキーパスを/ appAに変更し、別のアプリケーションにアクセスしてクッキーパスにアクセスした場合でも再ログインする/ Applicationを選択してから、変更されたパスにアクセスします。ログインするように求められなくなりましたが、ログインしたユーザー情報は失われます。 この実験を行う際には、基本的な認証方法のブラウザとWebサーバーが、セッションを通じて2番目の要求認証に対処する他の方法を持っているため、認証方法ではFORMを使用する必要があります。 詳細については、[7] secion 14.8を参照してください。認可、これらの実験を行うために添付のサンプルプログラムを変更することができます。

8つの要約
しかし、セッションメカニズム自体は複雑ではなく、その実装と構成の柔軟性によって、特定の状況が複雑かつ変更可能になります。 これはまた、我々が普遍的な経験としての単一の経験またはブラウザ、サーバーエクスペリエンスであってはならないことを要求しますが、常に特定のケース固有の分析である必要があります。
要約:Webアプリケーションでは、セッションメカニズムが長い間採用されていますが、多くの場合、セッションメカニズムの性質を理解できず、この手法を正しく適用することすらできません。 この記事では、セッションの仕組みと、Java Webアプリケーションでセッションメカニズムを適用する際によくある質問への回答について詳しく説明します。

カテゴリ:Default 時間:2018-05-14 人気:1

関連記事

Copyright (C) socapnw.com, All Rights Reserved.

Socapnw All Rights Reserved.

processed in 0.409 (s). 9 q(s)