Sharing Resources Using the Servlet Context
l Servlet Context
1. 모든 환경 정보를 가지고 있음
2. Application level의 객체
3. Web Application == Context
l ServletContext API가 제공하는 주요 기능
1. Context Parameter
u Read-only access to application scoped initialization parameters
u getInitParameter(name)
2. Application scope 객체 및 변수 공유
u Read-write access to application scoped attributes
u getAttribute(name)
u setAttribute(name, val)
3. 파일 읽기
u Read-only access to application-level file resources
u getResource(path)
4. logging 기능
u Logging functionality (Write)
l Listener
n A Context listener is used to initialize the catalog resource
n Listener를 통해 공유해야 하는 자원을 initialize 상태일 때 바로 공유시킬 수 있음
n Listener element는 반드시 context-param element 뒤에 와야 하며, servlet definitions 앞에 와야 함
n Listener은 사용하기 위해서는 Web.xml에 클래스를 등록해야 함
n Listener은 여러 개 지정 가능, Web Container 기동 시 지정된 순서대로 호출, 종료 시 역순
Developing Web Applications Using Session Management
l HTTP의 문제점
n Request 후 연결을 유지 하지 않음
n 상태 역시 유지되지 않음
n 어떻게 상태를 유지? è 실제 유지 하는 것이 아니라 유지 하는 것처럼 보이게 함
l 쿠키(Cookie)
n 쿠키, 즉 사용자에 대한 작은 정보를 의미
n 이 쿠키는 Header를 통해 클라이언트에게 전달
n Text 파일 형태로 로컬 피시 저장함
n 다음 Request시 Header의 Cookie를 보고 서버에서 처리
n ServletAPI 안의 Cookie Class 사용
l 쿠키의 단점
n 문자열(String)만 저장
n 256문자 이하 (영문 기준)
n File로 저장하기 때문에 보안에 취약
n File은 4KB 이하
n 쿠키 파일 수는 300개 이하만 가능
n Web Browser에서 차단 가능
n 수명이 다되면 브라우저에 의해 삭제
l SESSION 세션
n HTTP의 단점 및 쿠키의 약점을 보안할 만한 상태 유지 수단
n Request 요청 시 Session 영역에 해당 정보를 저장
n Session 영역은 링크가 끊어진 뒤에도 Session time out 기간 동안은 사라지지 않음
n 쿠키와 다르게 정보는 서버에서 보관
n Session ID 값만 헤더와 함께 클라이언트로 돌아감 (내부적으로 쿠키 사용과 동일)
n 재 요청 시 전달된 Session ID를 통해 Session 영역 연결
n Session Time out 적용은 마지막 Request에서 시간 적용
l Session 종료
n 타임 아웃
n 세션 객체의 invalidate() 호출
n Application의 다운
l Session의 장점
n Cookie보다 보안성 향상 (Session ID만 클라이언트가 가짐)
n Session은 어떤 객체라도 가능함 (Java Heap 메모리 영역을 사용하기 때문)
l Session의 단점
n Session ID 역시 쿠키형태로 저장되기 때문에 브라우저에서 쿠키 차단 시 문제 발생
u 해결책? URI 단에서 Session ID 부여 (좋은 방법이 아님)
u HTML에서 사용이 불가능 하며 JSP, Servlet 사용 가능
n 브라우저 종료 시에는 모든 Session 정보가 사라짐