이번 주는 새로운 환경인 게더에 적응하고 새로운 조원분들을 만나 프로젝트를 진행하다 보니 정신없이 지나간 것 같다.
첫 번째 주는 사전과제에서 공부한 지식을 바탕으로 프로젝트를 완성하기였고
필수 포함 사항이 있었다.
- 쿠키/세션 방식으로 로그인을 구현하고 → JWT 인증 방식으로 바꿔보기
- Jinja2 템플릿 엔진을 이용한 서버사이드 렌더링
첫 프로젝트를 통해 배우게 된 위의 필수 포함 사항들에 대해 장단점을 정리해봤다.
Session/Cookie 방식
세션은 서버가 가지고 있는 정보로써 보통 세션 저장소에 저장하고 유저가 로그인을 하게 될시 유저에게 고유한 ID를 부여해서(session) 저장소에 저장한 후 해당 세션과 연결된 세션 ID를 발급한다.
클라이언트에서는 인증이 필요한 요청이 있을 때 쿠키를 헤더에 넣어서 서버로 보낸다.
서버에서는 클라이언트에게서 받은 쿠키와 세션 저장소의 세션을 가져와 비교한 후, 일치한다면 로직을 수행한다.
장점
- 세션을 사용하면 유저의 정보를 서버에 저장해놓기 때문에 보안상 안전하다.
- 로그인 서비스에는 대부분 HTTPS로 되어있기 때문에 쿠키를 탈취한다고 해도 정보를 얻어내기 어렵고, 만료시간을 설정함으로써 더욱 보안을 유지할 수 있다.
- 서버는 쿠키의 값을 받았을 때 일일이 회원정보를 확인하지 않고 어떤 회원인지 알 수 있기 때문에 서버 접근성이 높다.
단점
- 세션이 서버의 자원을 사용하기 때문에 서버에 부하가 있을 수 있다.
- 쿠키 자체는 노출되도 큰 문제가 없다고 했으나, 사용자가 보낸 요청을 해커가 탈취하여 해당 쿠키로 서버에 변질된 내용으로 HTTP요청을 보내면 서버는 해커의 요청을 사용자로 인식하게 된다.
- 중앙 세션 저장소 관리가 없으면 시스템 확장이 어렵다.
토큰 기반 인증 방식(JWT)
JWT(Json Web Token)은 토큰 기반 인증 방식으로, 사용자의 세션 상태를 저장하는 게 아니라 필요한 정보를 토큰에 저장해 사용자가 가지고 있고 그것을 증명서처럼 사용한다. 사용자는 Access Token(JWT Token)을 헤더에 실어 서버로 보낸다.
토큰을 만들기 위해서는 Header, Payload, Verify Signature가 필요하다.
장점
- JWT는 발급한 후 토큰 검증만 하면 되기 때문에 추가 저장소가 필요 없다.
- 서버를 확장하거나 유지, 보수하는데 유리하다.
- 토큰 기반으로 하는 다른 인증 시스템에 접근이 가능 (Facebook 로그인, Google 로그인 등은 모두 토큰을 기반으로 인증)
단점
- Session/Cookie의 경우 세션ID가 변질되었다고 판단되면 해당하는 세션을 지우면 되지만 JWT는 한 번 발급되면 유효기간이 완료될 때 까지는 계속 사용이 가능하므로 유효기간이 지나기 전가지 정보들을 탈취할 수 있다.
- payload 정보가 제한적이고 따로 암호화되지 않기 때문에 디코딩하면 누구나 정보를 확인할 수 있어서 담는 데이터가 제한적이다.
Jinja2 템플릿 서버사이드
SSR(Server Side Rendering)는 기존에 존재하던 방식으로 사용자가 웹 페이지에 접근할 때, 서버에 페이지에 대한 요청을 하며 서버에서는 html, view 와 같은 리소스들을 어떻게 보여질지 해석하고 렌더링하여 사용자에게 반환한다.
장점
- 초기 구동속도가 빠르다.
- 완성된 페이지의 형태로 응답되기때문에 검색엔진에 최적화 가능하다
1주 차 첫 프로젝트가 끝나고 바로 알고리즘 공부를 시작했다.
강의를 보는데 이해하려고 노력해봐도 너무 어렵고 힘들었다..😞
조원분들이나 다른 조 사람들에게 어떤지 물어보면 똑같이 어렵다고 하시는 것 같았다.
잠은 쏟아지고 집중력도 떨어지는데 열심히 늦게까지 공부하는 다른 분들을 보면 정신차리고 다시 앉아서 집중하게 된다..!! 알고리즘.. 막막하지만 강의를 반복해서 보면서 최대한 이해하려고 노력해야겠다!
