애도 처음에 개발 시작했을때.. 완전 편하다.
세션에 값 다 넣으면 되네! 라고 하면서 이것저것 찾아보고 공부했었는데, 막상 시간이 지나고서 보니
그냥 가져다 쓰기만하고 어떻게 썻는지 어떤 특성이 있는지를 설명 못하겠었음.
"세션에 값넣고 꺼내~ " , "세션 지우면 되지~" 이런식으로만 말하고 사용했던거 같음....ㅜㅜ
그래서 다시 공부할겸 내용을 정리함
HTTP (Hypertext Transfer Protocol)는 웹에서 데이터를 주고받는 프로토콜입니다. HTTP 프로토콜의 특징은 다음과 같습니다.
HTTP 프로토콜은 웹을 구성하는 중요한 요소입니다.
- Stateless
HTTP는 Stateless 프로토콜입니다. 이는 서버가 클라이언트의 상태를 유지하지 않는다는 것을 의미합니다.
서버는 각각의 요청을 독립적인 것으로 처리하며, 이전 요청과는 상관없이 응답합니다.
- Connectionless
HTTP는 Connectionless 프로토콜입니다. 이는 서버와 클라이언트 간의 연결을 유지하지 않는다는 것을 의미합니다. 클라이언트가 요청을 보내면, 서버는 해당 요청에 대한 응답을 보낸 후에 연결을 종료합니다.
- 기본적으로 평문(Plain text)
기본적으로 평문으로 데이터를 전송합니다. 따라서 데이터의 내용이 암호화되지 않으므로, 중간에 데이터를 가로채어 보는 중간자 공격이 가능합니다.
- Request-Response 모델
Request-Response 모델을 따릅니다. 클라이언트가 서버에 요청을 보내면, 서버는 해당 요청에 대한 응답을 반환합니다. 이러한 요청-응답 모델은 웹 애플리케이션의 동작 원리를 이해하는 데 중요합니다.
- Stateless, Connectionless 때문에 쿠키와 세션 등의 매커니즘이 필요
HTTP의 Stateless, Connectionless 특성 때문에, 서버는 클라이언트가 보낸 요청이 어떤 세션과 관련되어 있는지 알 수 없습니다. 따라서, 이를 처리하기 위해 쿠키와 세션 등의 매커니즘이 필요합니다.
- 다양한 메서드 제공
다양한 메서드(GET, POST, PUT, DELETE, HEAD 등)를 제공합니다. 이러한 메서드들을 이용하여 클라이언트는 서버에 대해 특정 동작을 요청할 수 있습니다.
HTTP Session은 클라이언트와 서버 간의 상태 유지를 위해 사용되는 메커니즘입니다.
Session은 서버 측에서 클라이언트의 상태 정보를 저장하는 방식입니다.
Session은 서버 측에서 생성되며, 클라이언트가 애플리케이션과 상호작용하는 동안 유지됩니다.
Session은 일반적으로 인증, 사용자 프로필 정보, 장바구니 등과 같은 정보를 저장하기 위해 사용됩니다.
클라이언트가 서버에 접속하면 서버는 클라이언트에게 Session ID를 발급하여 저장하고, 이후 클라이언트가 서버에 요청을 보낼 때마다 이 Session ID를 이용하여 클라이언트의 상태 정보를 식별합니다.
Session ID는 보통 쿠키(Cookie) 또는 URL Rewriting을 통해 클라이언트에 저장됩니다.
Session은 서버 측에서 관리되기 때문에 보안에 강하고, Cookie와 달리 클라이언트 측에서 변경할 수 없습니다.
또한 Session은 브라우저를 종료하면 자동으로 삭제됩니다.
쿠키와 URL Rewriting 중 어느 하나를 선택해서 사용하는 것이 좋습니다.
보안 문제가 우려되는 경우에는 쿠키를 사용하는 것이 적절하며, 호환성 문제가 우려되는 경우에는 URL Rewriting을 사용하는 것이 적절할 수 있습니다.
## 쿠키에 저장
쿠키는 클라이언트 컴퓨터에 작은 텍스트 파일로 저장됩니다.
서버는 클라이언트에게 Session ID를 쿠키에 저장하도록 요청하고, 이후 클라이언트는 쿠키를 보내면서 해당 세션 ID를 서버에 전송합니다.
이를 통해 서버는 클라이언트의 세션 정보를 유지하고 관리할 수 있습니다.
- 장점:
쿠키는 사용자 컴퓨터에 저장되므로, 클라이언트 측에서 쉽게 접근할 수 있습니다.
서버 측에서 쿠키를 설정하고 삭제할 수 있으므로, 유연하게 세션을 관리할 수 있습니다.
- 단점:
쿠키는 사용자 컴퓨터에 저장되므로, 해커가 쿠키를 탈취하여 보안 문제가 발생할 수 있습니다.
사용자의 브라우저 설정에 따라 제한될 수 있으며, 쿠키를 거부하는 사용자도 있을 수 있습니다.
## URL Rewriting
URL Rewriting은 세션 ID를 URL 뒤에 포함시켜 전달하는 방식입니다.
이를 통해 클라이언트가 요청하는 모든 페이지 URL 뒤에 세션 ID가 추가됩니다.
서버는 URL에서 세션 ID를 읽어와 세션 정보를 유지하고 관리합니다.
- 장점:
URL Rewriting은 쿠키와 달리 사용자 컴퓨터에 저장되지 않으므로 보안상의 이슈가 적습니다.
URL Rewriting은 모든 브라우저에서 지원되므로 호환성 문제가 발생하지 않습니다.
- 단점:
URL Rewriting을 통해 전달되는 정보가 노출될 수 있으므로, 보안 이슈가 발생할 수 있습니다.
URL Rewriting은 URL이 길어질 수 있고, 이로 인해 가독성이 떨어지는 문제가 발생할 수 있습니다.
HTTP Cookie는 웹 사이트가 클라이언트(웹 브라우저) 측에 저장하는 작은 데이터 조각입니다.
Cookie는 클라이언트에 의해 생성, 유지되며, 서버에 의해서만 읽을 수 있습니다.
Cookie는 주로 사용자 인증, 세션 관리, 사용자의 기호 등을 저장하는 데 사용됩니다. 웹 사이트에서는 쿠키를 사용하여 사용자가 로그인했는지, 장바구니에 어떤 물건이 있는지 등을 파악하고 그 정보를 저장하고 유지할 수 있습니다.
Cookie는 이름-값 쌍으로 구성되며, 도메인, 경로, 만료 시간, 보안 등의 속성을 가질 수 있습니다.
Cookie는 서버가 HTTP 응답 헤더를 통해 생성하고, 클라이언트는 HTTP 요청 헤더를 통해 쿠키를 전송합니다.
Cookie는 브라우저가 종료되어도 유지될 수 있으며, 만료 시간을 설정하여 일정 기간 동안 유지될 수도 있습니다.
Cookie는 보안에 취약할 수 있으므로, 중요한 정보를 저장하거나 민감한 정보를 처리하는 경우에는 보안이 강화된 세션 기술 등을 사용하는 것이 좋습니다.
Cookie는 웹 개발에서 자주 사용되는 기술 중 하나이며, 웹 서버 및 웹 클라이언트 사이의 통신을 유지하고 개선하는 데 중요한 역할을 합니다.
1. Session 생성
클라이언트가 최초로 서버에 접속하면, 서버는 새로운 세션을 생성합니다. 이 세션은 서버 측에서 유지됩니다.
2. Session ID 전송
서버는 새로 생성된 세션 ID를 클라이언트에게 전송합니다. 이 세션 ID는 쿠키(cookie)를 통해 전송됩니다.
3. Session ID 저장
클라이언트는 전송받은 세션 ID를 쿠키에 저장합니다.
4. 클라이언트 요청
클라이언트가 다시 요청을 보내면, 이전에 저장한 세션 ID를 서버로 전송합니다.
5. Session 검색
서버는 세션 ID를 기반으로 이전에 생성한 세션을 검색합니다.
6. Session 데이터 처리
서버는 검색된 세션에 저장된 데이터를 처리합니다. 클라이언트가 전송한 요청을 처리하기 위해 필요한 데이터를 세션에서 가져올 수 있습니다.
7. Session 종료
세션은 일정 기간이 지나거나, 클라이언트가 세션을 종료하거나, 서버에서 세션을 종료할 때까지 유지됩니다. 세션이 종료되면, 서버는 해당 세션을 삭제합니다.
Session은 애플리케이션에서 중요한 역할을 하므로, 세션 관리는 보안상 매우 중요합니다.
Session ID는 보안적으로 안전한 방식으로 전송되어야 하며, 클라이언트가 전송한 요청을 검증하여 안전하게 처리해야 합니다.
또한, 세션은 필요하지 않은 경우에는 적시에 종료되도록 구현되어야 하며, 세션 데이터도 보안적으로 안전하게 저장되어야 합니다.
1. Cookie 생성
쿠키는 서버에서 HTTP 응답 헤더를 통해 생성됩니다.
응답 헤더에 Set-Cookie라는 헤더 필드가 포함되며, 이 헤더에 쿠키의 이름, 값, 속성 등이 설정됩니다.
2. Cookie 저장
브라우저는 서버에서 전송된 쿠키를 받아 로컬에 저장합니다.
쿠키는 브라우저마다 저장되는 위치가 다르며, 일반적으로 파일 시스템이나 브라우저 데이터베이스에 저장됩니다.
3. Cookie 전송
브라우저는 요청을 보낼 때 HTTP 요청 헤더에 쿠키를 포함하여 서버에 전송합니다.
서버는 이를 받아 쿠키의 값을 확인하고 적절한 응답을 반환합니다.
4. Cookie 만료
쿠키는 만료 시간이 지나면 더 이상 사용되지 않습니다.
쿠키의 만료 시간은 서버에서 설정할 수 있으며, 만료 시간이 지나면 브라우저에서 쿠키를 삭제합니다.
5. Cookie 삭제
브라우저에서는 사용자가 쿠키를 삭제할 수 있습니다.
또한, 쿠키가 만료되면 자동으로 삭제됩니다.
서버에서는 쿠키를 삭제하거나 만료시키는 응답 헤더를 전송할 수 있습니다.
HTTP 쿠키의 라이프 사이클은 이러한 과정을 거치면서 서버와 클라이언트 사이의 상호작용을 지원합니다.
쿠키를 사용하여 세션 상태를 유지하거나 사용자의 기호 등을 저장하고 활용할 수 있습니다.
자주 사용하는 메소드들 위주로 정리했습니다.
=================================================================================================================
@Controller
public class SessionController{
@RequestMapping(value="/test" , method = RequestMethod.GET)
public void sessionTest(HttpServletRequest request){
//세션을 가져옴
HttpSession session = request.getSession();
//세션에 값을 넣어줌
session.setAttribute("key" , "value");
//세션에서 값을 가져옴
session.getAttribute("key");
//세션의 ID를 가져옴
String sessionId = session.getId();
//세션에 속성을 지움
session.removeAttribute("key");
//세션 타임아웃 설정 ,초단위
session.setMaxInactiveInterval(시간);
//세션 제거
session.invalidate();
}
}
=================================================================================================================
new Session을 호출하면 새로운 세션 객체가 만들어지기 때문에 이전에 생성된 세션과는 다른 세션 객체가 반환
Spring은 HttpServletRequest.getSession() 메소드를 통해 HttpSession 객체를 생성하고, 이미 생성된 객체가 있다면 해당 객체를 반환하는 방식을 사용합니다.
- 세션 관리
HttpServletRequest.getSession() 메서드는 세션을 생성하거나 현재 요청과 연결된 세션을 반환합니다.
이 메서드를 사용하면 Spring에서 자동으로 세션을 관리할 수 있습니다.
Spring은 애플리케이션 컨텍스트를 초기화할 때 SessionRepositoryFilter를 자동으로 구성하므로 이 필터는 모든 HTTP 요청을 처리하고 요청과 연결된 세션을 찾아서 사용할 수 있습니다.
- 세션 스코프 빈
Spring에서 HttpServletRequest.getSession()을 사용하면 세션 스코프 빈을 사용할 수 있습니다.
세션 스코프 빈은 애플리케이션에서 세션을 통해 공유해야 하는 객체를 나타냅니다.
예를 들어 사용자가 로그인하면 로그인 정보를 세션에 저장하여 세션 스코프 빈에서 사용할 수 있습니다.
- 테스트 용이성
HttpServletRequest.getSession()은 MockMvc 테스트에서 쉽게 사용할 수 있습니다.
MockMvc는 Spring MVC의 테스트 지원 클래스로, HTTP 요청 및 응답을 시뮬레이트하고 컨트롤러를 테스트하는 데 사용됩니다.
MockHttpServletRequestBuilder.session() 메서드를 사용하여 테스트할 세션을 설정할 수 있으며, HttpServletRequest.getSession()을 사용하여 테스트 중인 세션에 액세스할 수 있습니다.
Spring에서 세션을 사용할 때 new Session()을 사용하지 않고 HttpServletRequest.getSession()을 사용하는 이유는 세션 관리, 세션 스코프 빈 사용, 테스트 용이성 등의 이점이 있기 때문입니다.