세션으로 로그인 구현하기 성공... 하... 너무나도 기쁨 하지만 까먹어버릴 위험이 크기 때문에 까먹지 않으려고 벨로그에 적어두려고 왔다!
이전 학원에서 세션 로그인 구현에 장렬하게 실패한 기억이 있는 바... 프론트에서 로그인 처리를 세션으로 해달라고 요청이 왔을 때 사실 잔뜩 쫄아있었다. 과연 내가 이번에는 할 수 있을 것인가...? 사실 못해도 해야 함... 당연함. 여긴 회사임.
지난번에 멀터로 사진 업로드 하는 것도 엄청 오랫동안 헤매다가 성공했을 때의 그 기쁨! 잊을 수 없었는데, 거의 그 급으로 신난다. 근데 멀터보다는 이해도가 조금 떨어지는 것 같긴 하다... 쿠키, 세션은 어려워잉.
다이어리를 보니 1월 12일부터 설정을 했고, 며칠간 대체 이게 뭔지 어떻게 하는지 감이 안 잡혀서 엉엉 우는 글을 쓴 것도 눈에 띈다. 흑흑 정말 힘들었어... 엉뚱한 코드도 엄청 썼던 것 같다 ㅋㅋㅋㅋ 하지만 해냄. 후후. (feat. 데정현의 도움... ><) 회사 정보가 드러나지 않게 ^^ 내가 했던 방식을 정리해보는 시간을 가져봅시다~
🥡 쿠키와 세션
우선 express-session을 사용하기에 앞서 쿠키와 세션에 대해서 알 필요가 있다.
🌐 HTTP 통신의 특징
우리가 인터넷 상에서 데이터를 주고 받을 때 HTTP 프로토콜을 사용한다. (서버/클라이언트 모델 기반) 클라이언트가 서버에게 요청을 보내면, 서버는 응답을 보내며 데이터를 교환한다.
비연결성(connectionless)과 무상태성(stateless)
HTTP는 냉정하게도 요청을 처리한 후 연결을 끊어버린다. 때문에 클라이언트의 상태 정보나 현재의 통신 상태를 잃어버리게 된다.
😀 이러한 비연결성은 서버의 자원 낭비를 줄일 수 있다는 점이다. 계속해서 요청을 해오는 수많은 클라이언트들과 쭉 연결이 유지된다고 생각해보자. 금세 서버에 과부하가 와서 터져버리고 말 것...
☹️ 그러나... 클라이언트의 상태 정보가 남아있지 않다는 것은 클라이언트를 식별할 수 없다는 것이다. 그 이야기는 우리가 로그인을 하고 다른 요청을 보낼 때 혹은 새로고침을 할 때 우리를 기억하지 못한다는 것이다. 계속해서 로그인을 해야 하는 말도 안되는 일이 발생하는 것이다.
이와 같은 단점을 극복하기 위해서 cookie와 session이라는 기술이 탄생하게 되었다.
🍪 쿠키(cookie)
아 쿠키 이모티콘 못 참지... 쿠키란 무엇이냐! 클라이언트가 웹 사이트에 방문할 시, 그 사이트의 서버를 통해서 클라이언트 브라우저에 설치되는 작은 기록 파일(데이터)을 말한다고 한다.
개발자 도구를 통해서 확인해볼 수 있다. 여기도 쿠키 이모지와 함께 내가 방문한 사이트의 쿠키 기록을 확인할 수 있다.
쿠키는 사용자가 요청하지 않아도 브라우저가 요청을 보낼 시, request header에 넣어져서 자동으로 서버에 전송이 된다.
그림에서도 볼 수 있듯이 <name> - <value>로 저장이 되며 Set-Cookie: userId=rosencrantz 이런 형식으로 여러가지 정보가 전송이 된다.
영속성을 가지고 있기 때문에 장기간 보존해야 하는 정보를 저장할 수 있다. (로그인 유지나 장바구니, n일간 보지 않기 등 우리가 인터넷을 쾌적하게 할 수 있게 만들어주는 고마운 친구,,,) 물론 쿠키가 만료되는 시간을 정해둘 수 있다.
클라이언트 측에 저장이 된 후 서버에 요청을 보낼 때마다 매번 저장된 쿠키를 요청 헤더의 cookie에 담아서 보낸다. → 이를 통해서 우리는 클라이언트가 누구인지 식별할 수 있게 되는 것이다!
☹️ 쿠키의 단점
문제는... 누구나 쿠키게 접근할 수 있다는 것! f12키만 누르면... 개발자도구 소환해서 쿠키에 담긴 정보들을 조회할 수 있다. (보안에 취약) 민감한 정보는 해싱 처리를 하지만, 브라우저에 저장이 됨으로써 브라우저에서 조작이 가능하기 때문에 중요한 데이터를 담아선 안된다. 또한 용량에 제한이 있기 때문에 많은 정보를 담기엔 적합하지 않다.
📥 세션(session)
쿠키와 완전 동떨어진 개념이 절대 아님! 세션은 쿠키를 기반으로 하고 있다. 무슨 말이냐! 세션을 생성할 때 발급되는 세션ID(클라이언트를 구분하기 위한 고유 번호)를 쿠키에 담아서(connect.sid라는 이름으로 생성되고, 원한다면 바꿀 수 있음) 통신을 하게 된다. 서로 반대되는 개념이 전혀 아니라 세션이 쿠키를 사용하여 통신하는 방식이라고 생각하면 된다.
하지만 클라이언트 측에 저장되는 쿠키와 달리 세션은 서버에 저장되고 서버 측에서 관리한다. 또한 이 세션은 클라이언트에서 생성할 수 없고 서버에서만 생성할 수 있다.
또한 쿠키는 영구 쿠키와 세션 쿠키가 있어서 만료 시간이 각각 다르지만 세션은 대부분 브라우저 종료 시 만료가 된다.
☹️ 세션의 단점
물론 이러한 세션도 단점이 존재한다. 세션은 서버에 저장이 되기 때문에 사용자가 많아지면 세션 DB와 서버를 확장해야 한다는 문제점이 있다.
또한 해커가 세션ID를 탈취하여 클라이언트인 척 위장을 할 수도 있다.
JWT라는 것도 있긴 한데... 이건 나중에 알아보자! 우선 오늘은 여기까지…
