Session——jsessionid
6242 ワード
サーバ側ではセッションに慣れていますsetAttribute(",userInfo)という行のコードでは、サーバとブラウザの間でどのようにセッション状態を維持しているかはあまり考えられません.では、まずいくつかの文章の素晴らしい断片を引用します.http://www.xxx.com/xxx_app;jsessionid=xxxxxxxxxx?a=x&b=x.
これは一般的なurlと基本的に同じで、ただ一つの違いがあります.それは「;jessionid=xxxxx」です.このパラメータは、urlの後ろに続くセミコロンで区切られた、一般的なrequestで区切られたパラメータであると言ってもよいし、ない場合もある.getParameter()メソッドはまだjsessionidを取得できません.
セッションの実現方式
web開発を行う学生は、httpが無状態のセッションプロトコルであることを知っています.つまり、ユーザーの情報を保存できないということです.では、ユーザーの閲覧活動を維持する必要がある情報があれば、どうすればいいのでしょうか.これらの情報を要求するたびにパラメータとしてサーバに渡すことができますが、これは面倒でリソースがかかり、セッションの重要性を体現しています.sessionはweb開発に不可欠な特性である.これは、特定のユーザーリクエストに対して、Webサーバに保存されるグローバル変数です.これにより、サーバとクライアントの間でやり取りすることなく、ユーザーの情報をサーバに保存できます.セッションの役割を知ったら、セッションはどのように実現しますか?サーバにはユーザーごとにセッションが保存されていますが、ユーザーが要求したとき、どのようにしてユーザーがどのセッションに対応すべきかを知っていますか?このときjsessionidが役に立ちます.各セッションにはIDとしてidがあり、このidはクライアントに転送され、クライアントリクエストのたびにこのidがサーバに転送され、サーバはidに基づいて今回のリクエストがどのセッションを使用すべきかをマッチングします.jsessionidはクライアントがsessionidを保存するための変数であり,主にj 2 eeで実現されるwebコンテナに対して,他の言語がどのような変数で保存されているかは検討されていない.一般的にWebアプリケーションでは、クライアント変数はクッキーに保存され、jsessionidも例外ではありません.しかし、一般的なクッキー変数とは異なり、jsessionidはメモリクッキーに保存されており、一般的なクッキーファイルでは影が見えません.メモリクッキーはブラウザウィンドウを開くと作成され、このブラウザウィンドウを閉じると同時に破棄されます.これは,session変数がウィンドウ間で使用できない理由を説明し,ウィンドウ間で使用するにはjsessionidをクッキーに手動で保存する必要がある. jsessionidの役割以上の文字ではsessionの実現原理を理解するとともに,sessionとjsessionidの密接な不可分なつながりも知った.jsessionidによってのみセッションメカニズムが機能し、jsessionidはクッキーによって保存されます.ここを見ると、ユーザーがクッキーを無効にした場合、jsessionidは保存できないという問題に気づくかもしれません.セッションは役に立たないのではないでしょうか.私たちは本当にこれに手の施しようがありませんか?もちろん違います.ユーザがクッキーを無効にした場合,url書き換えによりjsessionidの伝達を実現できる.これが私が指摘したようなurlです.http://www.xxx.com/xxx_app;jsessionid=xxxxxxxxxx?a=x&b=x...Jessionidは、クライアントからサーバ側にこのように伝達され、sessionを識別する.注意、jsessionidは一般的なurlパラメータ伝達方式とは異なり、パラメータとして付いているのではないでしょうか.後ろで、urlの後ろについて使います.で区切ります.これにより、ユーザーがクッキーを無効にするときにjsessionidを渡してsessionを使用することもできますが、毎回jseesionidをパラメータとしてurlの後に渡す必要があります.それは面倒ではないでしょうか.urlを1つ要求するたびに、cookieが利用可能かどうかを判断し、cookieを無効にした場合、urlからjsessionidを解析し、処理後に回ったurlの後ろについて、jsessionidの伝達を維持します.これらの問題sunはもちろん私たちに考えてくれたので、2つの方法を提供して簡単になりました:response.encodeURL()とresponse.encodeRedirectURL().この2つの方法はクッキーが使用可能かどうかを判断し、無効にするとurlのjsessionidが解析され、指定したurlの後ろに接続され、jessionidが見つからないと自動的に生成されます.なぜ2つの方法があるのでしょうか?この2つの方法は何が違いますか?Googleでは、この2つの方法はjsessionidを含めるかどうかを判断する論理的にやや異なると述べた.HttpServeretResponseを呼び出す.sendRedirectの前に、encodeRedirectURL()メソッドを呼び出す必要があります.そうしないと、Sesssion情報が失われる可能性があります.この2つの方法の使用方法はresponse.sendRedirect(response.encodeURL("/myapp/input.jsp"));.クッキーが無効になっていない場合、ブラウザのアドレスバーに表示されるアドレスは、/myapp/input.jsp、クッキーを無効にすると、/myapp/input.jsp;jsessionid=73E6B2470C91A433A6698C7681FD44F4.だから、私たちはwebアプリケーションを書くとき、保険のためにプログラムの中のジャンプurlごとにこの2つの方法を使って、sessionの可用性を保証しなければならない.
あなたのtomcatを起動して、FireFox(愛してたまらない、必ずFireBugをインストールしなければなりません)を開いて、localhostを入力して、firebugを開いて、点のネット、あなたは見ることができて、ブラウザとサーバーのセッションの情報、ブラウザを提供します
(1)初回要求サーバ:
ブラウザの要求ヘッダ情報
Host
User-Agent
Accept
Accept-Language
Accept-Encoding
Accept-Charset
Keep-Alive
Connection
サーバ応答ヘッダ情報
Server
Set-Cookie
Content-Type
Content-Language
Content-Length
Date
(2)2回目のリクエストサーバ:
ブラウザの要求ヘッダ情報
Host
User-Agent
Accept
Accept-Language
Accept-Encoding
Accept-Charset
Keep-Alive
Connection
Cookie
サーバ応答ヘッダ情報
Server
Content-Type
Content-Language
Content-Length
Date
3回目、4回ごとに...N回目のリクエストサーバ,ブラウザ,サーバのリクエストヘッダ情報は,いずれも2回目のリクエストサーバと同様である.
(3)ただし、サーバ側に次のコードを追加すると、
Log.info("SessionId:"+ request.getSession().getId());
最初にサーバを要求すると、デフォルトで新しいセッションが作成され、セッションの有効時間範囲内でこの出力値は変わりません.そうしないと、サーバはセッションを再作成し、自然に、セッションIdも異なり、このコードの出力も自然に異なります.
(4)ブラウザでサーバと通信していることに注意してください.
ブラウザが私たちを助けてくれたことがあります.それは、最初にサーバーと通信すると、ブラウザはサーバーから戻ってきたSet-Cookieという健の値(
(5)もう一度注意しましょう:request.setAttribute(「sysuser」,userInfo)という言葉:
最初にサーバを要求すると、このコードはサーバのデフォルトで生成されたセッションに基づいてIDを取得し、sysuser=userInfoというキー値とフックを掛け(もちろん、userInfoは任意のオブジェクトであってもよい)、一意の関連を保証し、ユーザーがログインしているかどうかを検出することが実現されます.
セッションをユーザーがログインしているかどうかは関係ありません.
これは一般的なurlと基本的に同じで、ただ一つの違いがあります.それは「;jessionid=xxxxx」です.このパラメータは、urlの後ろに続くセミコロンで区切られた、一般的なrequestで区切られたパラメータであると言ってもよいし、ない場合もある.getParameter()メソッドはまだjsessionidを取得できません.
セッションの実現方式
web開発を行う学生は、httpが無状態のセッションプロトコルであることを知っています.つまり、ユーザーの情報を保存できないということです.では、ユーザーの閲覧活動を維持する必要がある情報があれば、どうすればいいのでしょうか.これらの情報を要求するたびにパラメータとしてサーバに渡すことができますが、これは面倒でリソースがかかり、セッションの重要性を体現しています.sessionはweb開発に不可欠な特性である.これは、特定のユーザーリクエストに対して、Webサーバに保存されるグローバル変数です.これにより、サーバとクライアントの間でやり取りすることなく、ユーザーの情報をサーバに保存できます.セッションの役割を知ったら、セッションはどのように実現しますか?サーバにはユーザーごとにセッションが保存されていますが、ユーザーが要求したとき、どのようにしてユーザーがどのセッションに対応すべきかを知っていますか?このときjsessionidが役に立ちます.各セッションにはIDとしてidがあり、このidはクライアントに転送され、クライアントリクエストのたびにこのidがサーバに転送され、サーバはidに基づいて今回のリクエストがどのセッションを使用すべきかをマッチングします.jsessionidはクライアントがsessionidを保存するための変数であり,主にj 2 eeで実現されるwebコンテナに対して,他の言語がどのような変数で保存されているかは検討されていない.一般的にWebアプリケーションでは、クライアント変数はクッキーに保存され、jsessionidも例外ではありません.しかし、一般的なクッキー変数とは異なり、jsessionidはメモリクッキーに保存されており、一般的なクッキーファイルでは影が見えません.メモリクッキーはブラウザウィンドウを開くと作成され、このブラウザウィンドウを閉じると同時に破棄されます.これは,session変数がウィンドウ間で使用できない理由を説明し,ウィンドウ間で使用するにはjsessionidをクッキーに手動で保存する必要がある. jsessionidの役割以上の文字ではsessionの実現原理を理解するとともに,sessionとjsessionidの密接な不可分なつながりも知った.jsessionidによってのみセッションメカニズムが機能し、jsessionidはクッキーによって保存されます.ここを見ると、ユーザーがクッキーを無効にした場合、jsessionidは保存できないという問題に気づくかもしれません.セッションは役に立たないのではないでしょうか.私たちは本当にこれに手の施しようがありませんか?もちろん違います.ユーザがクッキーを無効にした場合,url書き換えによりjsessionidの伝達を実現できる.これが私が指摘したようなurlです.http://www.xxx.com/xxx_app;jsessionid=xxxxxxxxxx?a=x&b=x...Jessionidは、クライアントからサーバ側にこのように伝達され、sessionを識別する.注意、jsessionidは一般的なurlパラメータ伝達方式とは異なり、パラメータとして付いているのではないでしょうか.後ろで、urlの後ろについて使います.で区切ります.これにより、ユーザーがクッキーを無効にするときにjsessionidを渡してsessionを使用することもできますが、毎回jseesionidをパラメータとしてurlの後に渡す必要があります.それは面倒ではないでしょうか.urlを1つ要求するたびに、cookieが利用可能かどうかを判断し、cookieを無効にした場合、urlからjsessionidを解析し、処理後に回ったurlの後ろについて、jsessionidの伝達を維持します.これらの問題sunはもちろん私たちに考えてくれたので、2つの方法を提供して簡単になりました:response.encodeURL()とresponse.encodeRedirectURL().この2つの方法はクッキーが使用可能かどうかを判断し、無効にするとurlのjsessionidが解析され、指定したurlの後ろに接続され、jessionidが見つからないと自動的に生成されます.なぜ2つの方法があるのでしょうか?この2つの方法は何が違いますか?Googleでは、この2つの方法はjsessionidを含めるかどうかを判断する論理的にやや異なると述べた.HttpServeretResponseを呼び出す.sendRedirectの前に、encodeRedirectURL()メソッドを呼び出す必要があります.そうしないと、Sesssion情報が失われる可能性があります.この2つの方法の使用方法はresponse.sendRedirect(response.encodeURL("/myapp/input.jsp"));.クッキーが無効になっていない場合、ブラウザのアドレスバーに表示されるアドレスは、/myapp/input.jsp、クッキーを無効にすると、/myapp/input.jsp;jsessionid=73E6B2470C91A433A6698C7681FD44F4.だから、私たちはwebアプリケーションを書くとき、保険のためにプログラムの中のジャンプurlごとにこの2つの方法を使って、sessionの可用性を保証しなければならない.あなたのtomcatを起動して、FireFox(愛してたまらない、必ずFireBugをインストールしなければなりません)を開いて、localhostを入力して、firebugを開いて、点のネット、あなたは見ることができて、ブラウザとサーバーのセッションの情報、ブラウザを提供します
(1)初回要求サーバ:
ブラウザの要求ヘッダ情報
Host
localhost User-Agent
Mozilla/5.0 (Windows; U; Windows NT 5.1; zh-CN; rv:1.9.2.6) Gecko/20100625 Firefox/3.6.6 Accept
text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language
zh-cn,zh;q=0.5 Accept-Encoding
gzip,deflate Accept-Charset
GB2312,utf-8;q=0.7,*;q=0.7 Keep-Alive
115 Connection
keep-alive サーバ応答ヘッダ情報
Server
Apache-Coyote/1.1 Set-Cookie
JSESSIONID=64D21B4D69DFB3041B6375C1932BD6CB; Path=/ Content-Type
text/html;charset=UTF-8 Content-Language
zh-CN Content-Length
242 Date
Mon, 28 Jun 2010 02:35:29 GMT (2)2回目のリクエストサーバ:
ブラウザの要求ヘッダ情報
Host
localhost User-Agent
Mozilla/5.0 (Windows; U; Windows NT 5.1; zh-CN; rv:1.9.2.6) Gecko/20100625 Firefox/3.6.6 Accept
text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language
zh-cn,zh;q=0.5 Accept-Encoding
gzip,deflate Accept-Charset
GB2312,utf-8;q=0.7,*;q=0.7 Keep-Alive
115 Connection
keep-alive Cookie
JSESSIONID=64D21B4D69DFB3041B6375C1932BD6CB サーバ応答ヘッダ情報
Server
Apache-Coyote/1.1 Content-Type
text/html;charset=UTF-8 Content-Language
zh-CN Content-Length
242 Date
Mon, 28 Jun 2010 02:37:51 GMT 3回目、4回ごとに...N回目のリクエストサーバ,ブラウザ,サーバのリクエストヘッダ情報は,いずれも2回目のリクエストサーバと同様である.
(3)ただし、サーバ側に次のコードを追加すると、
Log.info("SessionId:"+ request.getSession().getId());
最初にサーバを要求すると、デフォルトで新しいセッションが作成され、セッションの有効時間範囲内でこの出力値は変わりません.そうしないと、サーバはセッションを再作成し、自然に、セッションIdも異なり、このコードの出力も自然に異なります.
(4)ブラウザでサーバと通信していることに注意してください.
ブラウザが私たちを助けてくれたことがあります.それは、最初にサーバーと通信すると、ブラウザはサーバーから戻ってきたSet-Cookieという健の値(
JSESSIONID=64D21B4D69DFB3041B6375C1932BD6CB)を保存します.ブラウザを閉じない限り(タブを完全に閉じてはいけません)、ブラウザは2回目にサーバーに要求してから、このキー値のペアを持っています.サーバーに送信します.サーバは、同じユーザ(同じセッション)が開始したリクエストであることを認識します.(5)もう一度注意しましょう:request.setAttribute(「sysuser」,userInfo)という言葉:
最初にサーバを要求すると、このコードはサーバのデフォルトで生成されたセッションに基づいてIDを取得し、sysuser=userInfoというキー値とフックを掛け(もちろん、userInfoは任意のオブジェクトであってもよい)、一意の関連を保証し、ユーザーがログインしているかどうかを検出することが実現されます.
セッションをユーザーがログインしているかどうかは関係ありません.