HTTP 세션 문제점

HTTP(Hypertext Transfer Protocol) 세션을 작성하거나 사용할 때 문제점에 대한 문제점 해결 정보를 사용합니다.

여기 설명된 세션 관리자 설정값을 보고 업데이트하려면 관리 콘솔을 사용하십시오. 문제의 애플리케이션을 호스트하는 애플리케이션 서버를 선택하고 추가 특성 아래에서 웹 컨테이너를 선택한 후 세션 관리자를 선택하십시오.

발생하는 문제점의 종류
[IBM i]문제점이 여기에 기술되지 않거나 이 중 어느 단계도 문제점을 수정하지 못하는 경우

HTTP 세션이 작성되지 않거나 요청 사이에서 삭제되었음

기본적으로 세션 관리자는 요청 사이에 쿠키를 사용하여 클라이언트에 세션 ID를 저장합니다. 쿠키 기반 세션 추적을 피할 의도가 아니라면, WebSphere Application Server 및 브라우저 사이에 쿠키가 이동하는지 확인하십시오.
  • 세션 추적 메커니즘 특성 아래에서 Enable cookies 선택란을 선택했는지 확인하십시오.
  • 테스트하고 있거나 사용자가 애플리케이션에 액세스 중인 브라우저에서 쿠키가 사용 가능한지 확인하십시오.
  • 웹사이트에 지정된 쿠키 도메인을 확인하세요. SessionManager. 쿠키 설정을 보거나 업데이트하려면 세션 추적 메커니즘 > 쿠키 속성 활성화 , 클릭 수정하다 .
    • 예를 들어, 쿠키 도메인이 .myCom.com으로 설정된 경우 해당 도메인 이름으로 자원에 액세스해야 합니다. (예: https://www.myCom.com/myapp/servlet/sessionservlet).
    • 도메인 속성이 설정된 경우 점(.)으로 시작하는지 확인하세요. 이전 브라우저에서는 도메인 이름이 점으로 시작하지 않으면 쿠키를 허용하지 않을 수 있습니다. 최신 브라우저는 점이 있거나 없는 도메인을 존중합니다. 예를 들어 도메인 이름이 다음으로 설정된 경우 mycom.com, 다음으로 변경하세요. . mycom.com 모든 브라우저가 쿠키를 존중하도록 합니다.
      메모: 서버가 다른 호스트에 있는 경우 플러그인을 사용하여 웹 서버와 같은 프런트엔드 라우터를 구성하거나 쿠키 도메인을 설정하여 세션 쿠키가 모든 서버로 흐르도록 합니다.
  • SessionManager에서 지정된 쿠키 경로를 확인하십시오. 문제점 URL이 계층적으로 지정된 쿠키 경로 아래에 있는지 확인하십시오. 그렇지 않으면 쿠키 경로를 정정하십시오.
  • 쿠키 최대 유효기간 특성이 설정된 경우 시간대를 포함하여 클라이언트(브라우저) 머신의 날짜 및 시간이 서버의 날짜 및 시간과 같은지 확인하십시오. 클라이언트와 서버의 시간 차이가 쿠키 최대 유효 기간을 초과할 경우 쿠키가 액세스 후 만료되므로 모든 액세스는 새 세션이 됩니다.
  • 세션을 추적하는 엔터프라이즈 애플리케이션 내에 여러 개의 웹 모듈이 있는 경우
    • 하나의 엔터프라이즈 애플리케이션 내 웹 모듈 사이에 여러 다른 세션 설정을 가지려는 경우, 각 웹 모듈이 다른 쿠키 이름 또는 경로를 지정해야 합니다.
    • 하나의 엔터프라이즈 애플리케이션에 있는 여러 웹 모듈이 공통 쿠키 이름 및 경로를 사용하는 경우 쿠키 최대 유효 기간과 같은 HTTP 세션 설정이 모든 웹 모듈에 대해 동일해야 합니다. 그렇지 않으면, 쿠키 동작이 예측 불가능하며 세션을 작성하는 애플리케이션에 따라 달라집니다. 이는 웹 모듈이 별도로 유지보수하는 세션 데이터에 영향을 주지 않습니다.
  • 브라우저와 서버 사이의 쿠키 흐름을 확인하십시오.
    1. 브라우저에서 쿠키 프롬프트를 사용으로 설정하십시오. 서블릿을 시작하고 쿠키가 프롬프트되고 있는지 확인하십시오.
    2. [IBM i]서버에서 세션 관리자 추적을 사용 가능하게 하십시오. 추적 스펙 com.ibm.ws.session.*=all=enabled를 사용하여 HTTP 세션 관리자 컴포넌트에 대해 추적을 사용으로 설정하십시오. 추적이 사용 가능하게 된 후, 세션 사용 서블릿 또는 JSP를 사용해 보고 추적 출력 덤프 및 찾아보기 지시사항을 따르십시오.
    3. 브라우저에서 세션 서블릿에 액세스하십시오.
    4. 브라우저가 쿠키에 대해 프롬프트합니다. jsessionid를 기록해 두십시오.
    5. 서블릿을 다시 로드하고 새 쿠키가 전송된 경우 쿠키를 기록해 두십시오.
    6. 세션 추적을 확인하고 세션 ID를 찾은 후 스레드 요청을 추적하십시오. 세션이 웹 요청 사이에서 안정적인지를 확인하십시오.
      • 세션 요청의 시작인 getIHttpsession(...)을 찾으십시오.
      • 서블릿 요청의 종료인 releaseSession(..)을 찾으십시오.
  • 쿠키 대신 URL 재기록을 사용하는 경우
    • 애플리케이션 탐색 경로에 정적 HTML 페이지가 없는지 확인하십시오.
    • [IBM i]서블릿과 JSP 파일이 올바르게 URL 재기록을 구현하고 있는지 확인하십시오. 자세한 내용과 예시는 다음을 참조하세요. 세션 추적 옵션.
  • 더 이상 사용되지 않는 기능: SSL ID를 사용한 세션 추적은 다음에서 더 이상 사용되지 않습니다. WebSphere Application Server 버전 7.0. 쿠키를 사용하도록 세션 추적을 구성하거나, URL 재작성을 사용하도록 애플리케이션을 수정할 수 있습니다.
    세션 추적 메커니즘으로 SSL을 사용하고 있다면
    • IBM HTTP Server 또는 iPlanet HTTP Server에서 SSL이 사용 가능한지 확인하십시오.
    • [IBM i]검토 세션 추적 옵션.

세션이 동일한 클라이언트 시스템의 여러 브라우저 간에 공유됩니다.

이 작동은 브라우저에 따라 다릅니다. 브라우저 벤더 간에 차이가 있으며 브라우저를 새 프로세스로 실행했는지 또는 기존 브라우저 세션의 서브프로세스로 실행했는지에 따라 변경될 수 있습니다(예: Windows에서는 Ctl-N을 눌러).

쿠키가 세션 추적 메커니즘으로 사용되는 경우, 세션 관리자의 쿠키 최대 유효 기간 특성도 이 작동에 영향을 미칩니다. 최대 유효 기간이 일부 양수 값으로 설정되는 경우, 모든 브라우저 인스턴스가 지정된 최대 유효 기간에 대해 클라이언트의 파일로 지속되는 쿠키를 공유합니다.

세션이 지정된 세션 제한시간 후 바로 무효화되지 않음

세션 관리자 무효화 프로세스 스레드가 x초마다 실행되어 유효하지 않은 세션을 무효화시킵니다. 여기서, x는 세션 관리자 특성에 지정된 세션 제한시간 간격을 기준으로 결정됩니다. 기본값이 30분인 경우, x는 300초 정도입니다. 이 경우, 특정 세션이 무효화되려면 제한시간 임계값 30분을 지나 최대 5분(300초)이 걸릴 수 있습니다.

JavaServer Pages가 원치 않는 세션을 작성하고 있습니다.

JSP(JavaServer Pages) 스펙에 필요하므로, JSP는 기본적으로 클라이언트용 세션이 하나도 없는 경우 세션을 작성하도록 request.getSession(true)을 수행합니다. JSP 페이지가 새 세션을 생성하지 못하도록 하려면 세션 범위를 다음으로 설정하세요. 거짓 에서.jsp 다음과 같이 페이지 지시문을 사용하여 파일을 생성합니다.
<% @page session="false" %>
[IBM i]

하나의 클라이언트만을 위한 세션 데이터가 다른 클라이언트에 표시됨

보기 드문 상황에서, 보통 애플리케이션 오류로 인해 하나의 클라이언트만을 위한 세션 데이터가 다른 클라이언트에 표시될 수 있습니다. 이러한 상황을 세션 데이터 크로스오버라고 합니다. DebugSessionCrossover 사용자 정의 특성이 true로 설정되는 경우 세션 데이터 크로스오버의 인스턴스를 발견하여 로깅할 수 있습니다. 요청과 연관된 세션만 액세스 또는 참조되었는지 확인하는 검사가 수행됩니다. 불일치가 발견되면 메시지가 로깅됩니다. 이 메시지는 문제점의 디버깅을 위한 시작점을 제공합니다. 이러한 추가 확인은 사용자가 작성한 스레드가 아니라 WebSphere에서 관리하는 디스패치 스레드에서 실행 중일 경우에만 수행됩니다.

이 속성을 설정하는 방법에 대한 자세한 내용은 다음을 참조하세요. 웹 컨테이너 사용자 정의 속성.

또한 Java 프록시 또는 Java On Demand Router를 사용하는 경우 다음 중 하나를 사용하여 테스트하는 것을 고려할 수 있습니다.http.cache.nocache.headers="Set-Cookie,Set-Cookie2" 그리고cache.query.string=true (보다 HTTP 프록시 서버 사용자 정의 특성 자세한 내용은) - 또는 - 선택 취소Enable caching 캐싱을 완전히 비활성화하려면(참조 프록시 서버 설정 상세 사항은). 이러한 변경사항에는 성능 영향이 있을 수 있으므로 미리 테스트해야 합니다.

HTTP 세션 타이머가 만기된 후 사용자가 로그아웃되지 않음

WebSphere Application Server의 사용자가 응용프로그램에 로그온하여 지정된 HTTP 세션 제한시간 값보다 오래 유휴 상태인 경우, 사용자 정보가 무효화되지 않고 LTPA 토큰 제한시간 초과가 발생할 때까지 사용자 신임이 활성 상태로 유지됩니다.

다음 단계를 완료하여 HTTP 세션이 만기된 후 사용자를 애플리케이션에서 로그아웃하십시오.
주목: 그만큼com.ibm.ws.security.web.logoutOnHTTPSessionExpire 속성은 양식 로그인을 사용하는 애플리케이션에만 적용됩니다.
  1. 관리 콘솔에서 보안 > 글로벌 보안을 클릭하십시오.
  2. 사용자 정의 속성에서 새로운.
  3. 이름 필드에 com.ibm.ws.security.web.logoutOnHTTPSessionExpire를 입력하십시오.
  4. 값 필드에 true를 입력하십시오.
  5. 적용 및 저장을 클릭하여 구성에 대한 변경사항을 저장하십시오.
  6. 서버를 재동기화 및 다시 시작하십시오.
예상치 못한 재인증: 설정하면 com.ibm.ws.security.web.logoutOnHTTPSessionExpire 사용자 정의 특성을 true로 설정하면 여러 웹 애플리케이션으로 작업할 때 예기치 않은 재인증이 발생할 수 있습니다. 기본적으로, 각 웹 애플리케이션에는 고유 HTTP 세션이 있지만 웹 브라우저에는 단일 세션 쿠키가 있습니다. 이 문제를 해결하려면 각 애플리케이션에 고유한 세션 쿠키 이름을 부여하거나 경로를 설정하여 HTTP 세션 구성을 변경하면 됩니다. 이렇게 하면 각 애플리케이션이 고유 세션 쿠키를 확보합니다. 다른 방법으로, 여러 웹 애플리케이션에 동일한 엔터프라이즈 애플리케이션을 구성하여 동일한 HTTP 세션을 공유하도록 할 수 있습니다. 자세한 정보는 세션 데이터를 공유할 수 있도록 어셈블 주제를 참조하십시오.

세션 지속성이 사용되는 애플리케이션을 업데이트할 경우 런타임 중에 예외가 발생할 수 있습니다.

세션 지속성이 사용 설정되고 런타임 시 업데이트를 실행하는 사용자는 애플리케이션이 다시 시작된 후 예상치 못한 예외를 경험할 수 있습니다.

저장된 속성을 변경하는 업데이트가 작성되면 애플리케이션이 이러한 변경사항을 처리할 수 없는 경우 애플리케이션 업데이트 이전에 연관된 애플리케이션에서 작성한 세션을 모두 무효화해야 합니다. 이러한 상황에서는 모든 세션 오브젝트를 백엔드에서도 제거해야 합니다. 이러한 세션을 적절히 제거하는 방법에 대해 계속 학습하려면 HTTP 세션 무효화 정보를 참조하십시오.

IBM 지원에는 문제점 해결에 필요한 정보 수집 시간을 줄일 수 있는 문서 및 도구가 있습니다. 문제 보고서를 열기 전에 제품 지원 페이지를 참조하십시오. https://www.ibm.com/mysupport/s/topic/0TO500000001DQQGA2/websphere-application-server.