1017 | 인증과 권한 개념, 세션과 쿠키

✅ 인증과 권한

1. 윈도우프로그램을 만들던 시절(클라이언트중심)

앱에서는 사용자가 사용자정보 (아이디와 패스워드)를 넣으면 어딘가에 남겨지게 되어있음.

사용자가 화면에 접근하려고 하면 인증이 있음/없음을 구별해서 사용하게 함

 

2. 현재 웹어플리케이션은

인증정보를 클라이언트가 아닌 서버가 저장하게 되어있음

html과 css만 다루는 환경에서는 다른메뉴를 클릭할 경우 ▶ 서버에요청 ▶ 서버에서 다른 페이지로 연결해줌. ▶요청에 대해서 그때그때 서블릿이 생겼었음.

 

3. 세션이 생긴 배경

서버에서 서블릿들은 생겼다 사라지지만 인증정보가 사라지면 안됨. 이때 활용할 수 있는  '계속 존재하는 공간'은 어플리케이션(서버에서 사용하는 전역변수공간)과 세션임 

 

이때 세션은 공간이라 생각하면 안됨. 정확학는 세션== '기간'을 뜻한다.

 

웹은 세션이란 기간을 두고 ,나랑 대화하는 사용자가 있다, 없다를 생각한다.

(사용자가 나를 다시 찾을지 여부에 대한 기다림의 기간. 여러 클라이언트로부터 페이지 요청을 받으므로 한 사용자에게 무한대로 접속 시간을 제공할 수 없다 & 보안문제!)

 

4. 세션이 기간인 이유

서버는 클라이언트 한명이 다섯번 요청한건지, 다섯명이 한번씩 요청한건지 알 수가 없음 ▶ 따라서 사용자를 위한 저장공간을 마련해야 한다.(해당 사용자가 하는 행위, 프로필정보 등을 저장하기 위해 전용공간인 세션을 설정할 수 밖에 없다) ▶ 사용자를 식별하는 방법이 필요하다 ▶ 공유기 ip를 가지고 식별이 불가함(사설아이피로 요청할 일이 없고 같은 공유기를 쓰면 그 집 컴퓨터는 다 같은 ip를 가진다)  ▶ 서버로부터 식별자가 발급된다 (SID발급)

 

• 세션 == 사용기간 (자원 사용을 허락받은 시간)
• 서버의 (세션)공간을 사용할 수 있다 (*사용할 자원이 있어야 한다)
• 공간을 사용하기 위해서는 (세션)키가 필요하다. (이 키는 보안키/세션아이디/SID로도 불린다)
• 톰캣의 default 세션 = 20분
• 세션 타임아웃을 따로 설정할 수도 있다.

SID를 발급받은 클라이언트는 접속할때마다 해당 저장공간을 정해진 시간동안 사용할 수 있다. (ex. 세션이 유지되는 동안 페이지를 넘어다니며 장바구니에 값을 저장해둬도 초기화가 되지않는다)

 

 

 

#️⃣ Session 생성해보기

@Controller
@RequestMapping("/")
public class HomeController { //기본값으로 string을 설정해서 세션에 전달해봄
	
	@RequestMapping("index")
	public String index( @RequestParam (defaultValue="octap")String hello, HttpServletRequest request) {
		//서블릿이 다 죽어도 세션저장소는 키를 가진 사람만 쓸 수 있는 전역 공간이므로 죽지 않는다!
		HttpSession session = request.getSession();
		session.setAttribute("test",hello);
		return "index";
	}
}

처음 접속할때 서버로부터 cookie를 받는다

재접속할때는 쿠키값을 가지고 request한다

@Controller
@RequestMapping("/menu")
public class MenuController {

	@Autowired
	private MenuService service;

	@RequestMapping("list")
	public String list(Model model, HttpServletRequest request) {
		HttpSession session = request.getSession();
// 다른코드 생략
		System.out.println(session.getAttribute("test")); // 다른컨트롤러에서 넣은 test의 값이 나온다
		return "menu/list";
	}

👉 세션을 생성하지않으면 똑같이 접속해도 SID를 받질 않음! 개발자도구의 어플리케이션으로 가도 cookie를 확인할 수 없음!

👉 세션이 살아있는 동안은 어느 서블릿에서든 (다른 페이지에서도) 세션을 꺼내볼 수 있다. ▶ 세션키(SID)만 가지고 다니면 된다. (만약 세션키를 분실한다면 저장해놓은건 모두 잃어버림) -- 이때 세션키도 쿠키임!

 

 

---

 

 

#️⃣ 쿠키 개념

(** 개인화된 저장소는 쿠키와 세션으로 볼 수 있다.)

 

• 쿠키는 브라우저에 or 클라이언트에 저장하는 값.
• 서버가 저장하라고 알려준 값. (접속할때 처음만 설정되고 새로고침하면 사라짐)
• 캐비넷 키와 동일.
• 서버에 접속할때마다 가져가야함.
• 전체적으로 SID와 설명이 유사한것같은데, SID도 쿠키에 담겨서 이동된다!

 

 

 

#️⃣ 쿠키 생성하기

• 쿠키는 클라이언트가 가지고 있는 것. 
• 응답헤더에 set cookie로 들어감으로써 처음으로 받고, 페이지에 request할 때마다 Cookie를 가져간다.
• 그 이후로는 서버에서 response할때 cookie를 전달해줄 필요가 없다

 

@RequestMapping("list")
	public String list(Model model, HttpServletRequest request, HttpServletResponse response) {

		Menu menu = Menu.builder().engName("ame").build();

//코드생략

	Cookie cookie = new Cookie("cookietest", "octap");
			
		if (request.getCookies() ==null) // 쿠키가 하나라도 없을때 응답할때 쿠키를 부여한다
			response.addCookie(cookie);
		if(request.getCookies().length<0) //쿠키 최초 전달 후, response에 재전달하지 않기 위한 검증 
        	response.addCookie(cookie);

		return "menu/list";
	}

 

 

// 위의 list페이지에서 쿠키를 발급후, 상위페이지인 인덱스에서 쿠키를 찾아보았다

Cookie[] cookies = request.getCookies();
if (cookies != null) {
    for (Cookie cookie : cookies) {
        String name = cookie.getName();
        String value = cookie.getValue();
        System.out.println("Cookie Name: " + name);
        System.out.println("Cookie Value: " + value);
    }
} else {
    System.out.println("No cookies found in the request.");
}

👉 하위페이지(/menu/list) 에서 쿠키를 발급했을때, 상위페이지(/index)에서는 쿠키를 인식하지 못한다.

👉 list에 다시 재접속해보면 기존 쿠키가 인식되면서 값을 찾을 수 있다.

👉 반대로 index에서 쿠키가 발급되면 list에 접속해도 쿠키를 확인할 수 있다.

👉 세션은 상하페이지 상관없이 서블릿을 통해 공유된다. (session.setAttribute(), session.getAttribute());

 

 

 

 

 

 

 

✅ 세션과 쿠키 전체적으로 재정리 (아래 블로그 참고)

쿠키와 세션 개념

 

HTTP는 두가지 특징을 가진다 (connectionless, statelss) ▶ 응답을 하면 연결을 끊어버리는 특성. & 연결을 끊는 순간 클라이언트와 서버의 통신이 끝나며 상태정보는 유지하지 않는다 ▶ 이 연결을 유지하기 위해 세션과 쿠키를 사용한다 (인증유지)

 

세션	쿠키
서버에서 사용자 정보 파일을 관리함 (전용공간이 있음) 클라이언트 구분용으로 SID를 부여함 클라이언트가 웹브라우저 접속~종료까지 인증상태 유지 접속시간 제한 가능	클라이언트(브라우저)측에 저장되는 키&값 데이터파일 사용자 인증이 유효한 시간을 명시할 수 있음 인증시간 內  브라우저가 종료되어도 인증이 유지됨
서버 과부하 & 서버 메모리 부담이 올라감	서버 자원을 전혀 사용하지 않음
쿠키보다 보안에 좋다 (사용자 정보가 서버에 있으므로)	요청속도가 세션보다 빠르지만 스니핑당할우려가 있음
각 클라이언트에게 고유 ID를 부여 세션ID로 클라이언트를 구분해서 클라이언트에 맞는 서비스 제공	클라이언트의 상태정보를 로컬에 저장했다가 참조함 브라우저가 종료되어도 쿠키만료기간이 있다면 클라이언트에서 보관함 서버에서 쿠키를 읽어서 변경된 정보로 업데이트하여 응답 가능
세션 아이디도 쿠키를 사용해서 저장한다. (쿠키안에 SID만 심어두고 쿠키의 SID를 함께 서버에 전달해서 요청)	같은 요청을 할 경우, 사용자 요청 없이도 브라우저가 request할때 알아서 header에 넣어서 전송
로그인같이 보안상 중요한 작업	ex) 사이트에서 로그인시, 아이디와 비밀번호를 저장하시겠습니까? 쇼핑몰 장바구니 기능 자동로그인 팝업에서 '오늘 더이상 이 창을 보지 않음'

• 세션은 url이달라져도 뽑아쓸 수 있다 (서블릿에서 뽑아쓸 수 있다)
• url이 달라도 쿠키도 쓸 수 있다. 서버에 저장을 해놓느냐 그런거 없이 키만 가지고 다니느냐의 차이.
• 쿠키가 더 많은 능력을 갖고 있음.