The jsessionid key
There may be one thing in the browser source that you might not recognize as standard HTML.
The first time you visit this page, the sign-in link may actually look like this:
Sign in
Most web applications need to keep track of the people using the application.
HTTP has some rudimentary support for maintaining a user logon, but the approach is limited and not secure.
The Java servlet framework does provide support for a robust user session but needs a mechanism to maintain
the session across HTTP.
The jsessionid is a key maintained by the container to track the user session via HTTP.
Including the session key in a hyperlink is called URL rewriting. The Servlet Specification [Sun, JST] encourages
the use of cookies to maintain the session. When that is not possible, URL rewriting is used
instead. The first time a browser makes a request to the container, the container does not know
whether the browser will accept a cookie. The container can offer the browser a cookie, but can’ t
tell if it was accepted until the next time a request is made. (HTTP has no “ handshaking.” ) In the
meantime, the response for the current request must be written. So, the first page written for a
browser will always need to use URL rewriting. If on subsequent requests the container finds that
its cookie was accepted, it can skip rewriting the URLs.
클라이언트가 서버에 정보를 요청했을 때 중간에서 컨테이너가 받아서 결정해서 보내는데 여기서 같은 클라이언트가 정보를 또 요청했을 경우 이를 인식할 만한 세션아이디가 필요하다.
그게 바로 jsessionId라고 한다.?요청 request에 대한 response+jsessionId를 함께 덧붙혀서 준다.
즉 한마디로?클라이언트꼬리표라고 생각하면된다.
대체적으로 Set-cookie;JSESSIONID=어떤고유한값 이렇게 쓴다.?
[출처]?What is jsessionId?|작성자?햇살담은무지개
JSESSIONID이란 무엇일까요?
– WAS에서 사용하는 Session에 대한 ID 값을 가지고 있는 변수를 일반적으로 명칭이 JSESSIONID입니다.
위의 그림처럼 일반적으로 모든 WAS에서는 Session ID값을 가지고 있는 변수를 JSESSIONID이라고 합니다.
(Session ID 값은 도메인별로 발급되어 가지고 있게 됩니다.)
그러나 이처럼 알려진 JSESSIONID 변수명을 사용하기에는 하나의 WAS(동일한 도메인)에서 서로 Session ID를 독립적으로 가져야하는 두 개 이상의 어플리케이션에서 대해서 문제가 발생할 수 있습니다. 이에 대한 문제는 비정상적으로 logout이 될 수 있다는 것입니다.
즉, 하나의 어플리케이션에서 JSESSIONID이라는 변수명으로 Session ID 값을 가지고 동일한 도메인의 다른 어플리케이션으로 갔을 경우, JSESSIONID에 새로운 Session ID 값이 발급이 되게 됩니다.(이는 어플리케이션 끼리 Session ID를 독립적으로 가지고 있겠다고 하였기 때문이다.) 그렇기 때문에 다시 원래 어플리케이션 쪽으로 가서 확인하면 로그아웃이 되는 현상이 됩니다.(즉, Session 상태를 유지하지 못하고 있는 것입니다.)
그렇다면 이와 같은 현상이 없게 하기 위해서는 어떻게 하면 될까요?
방법 중의 하나는 어플리케이션에 대해서 Session ID값을 가지고 있는 변수명을 JSESSIONID 외 변수명으로 바꾸어주시면 됩니다. 이와 같이 하는 경우 동일한 도메인이어도 안에 있는 각각의 어플리케이션에 대한 Session ID 변수명이 다르기 때문에 각각의 어플리케이션에 대한 세션 정보를 독립적으로 유지할 수 있는 것입니다.
위 처럼 Session ID 변수명을 지정하는 것은 WAS마다 다르기 때문에, 이에 대한 정보는 검색 및 각 WAS의 메뉴얼을 참고하시기 바랍니다.
JEUS에서 Session ID 변수명을 지정할 수 있는 최소 단위는 Context-Group 단위로 할 수 있습니다.
관련된 태그는 Servlet Engine WEBMain.xml에서 context-group 안과 밖에서 적용될 수 있습니다.
다음 관련 태그 설정 예 입니다.(JEUS 6 기준)
…
JSESSIONID
…
[출처] [WAS]JSESSIONID에 대해서|작성자 풍운도
——————————————————————
JSESSIONID 는 동일 도메인에서만 작동합니다.
www.xxx.com 용 JSESSIONID와 myhome.xxx.com 용 JESSIONID 쿠키는 서로 전혀 다른 영역에 저장되는 것이지요.
이 문제는 cookie의 저장영역 때문이 맞습니다. 님 말씀대로 쿠키를 .xxx.com 으로 지정하면 해결이 가능하지요.
그런데, 이런식의 쿠키 지정은 Servlet Spec의 표준에 어긋납니다. 따라서 톰캣은 그런식의 JSESSIONID 쿠키 도메인 지정을 허락하지 않습니다. 저도 HttpResponse를 가로채는 방법을 시도해 봤으나, Tomcat 소스까지 쫓아 들어가본 결과, 결국은 톰캣이 그걸 막아버립니다.
하지만, WebLogic 등은 다중 도메인 세션을 허락합니다.
그래서 저 같은 경우는 세션을 제가 직접 만들었습니다. 다중 서버 환경에서 사용하기 위해 DB에 세션 정보를 넣는 테이블을 만들고 세션에 대한 관리만 전담하는 Servlet Filter를 만들어서 Servlet 컨테이너가 제공하는 세션이 아닌 제가 직접 만들 세션을 .xxx.com 쿠키로 지정하여 사용합니다.
DB로 세션을 만들지 않고, Cookie로 세션을 만들수도 있습니다. 포탈들도 아마 대부분 그렇게 하고 있을 껍니다. 물론, 철저하게 암호화를 해야지요.
순수 Cookie로 세션값을 저장하면 DB 액세스 타임이 절약되기 때문에 약간 더 빠릅니다.