Today I Learned 4일차
- 1차 미니 프로젝트 배포!
- JWT vs Session vs Cookie
- SSR vs CSR
- 느낀점 (첫 프로젝트를 마무리하며..)
1. 1차 미니 프로젝트 배포!
6월 7일 월요일부터 시작되었던 미니 프로젝트 개발이
오늘 저녁, AWS 서버 배포를 마지막으로 마무리가 되었다.
당장 출시할 정도로 안정적이고 완성도가 높은 서비스는 아니지만
미니 프로젝트인 만큼 다양한 기능보다는 기본적인 기능들에 집중하였고
덕분에 개발을 하는 동안은 기능의 '작동 유무'보다는 그에 맞는 '효율적인 성능'에 집중할 수 있는 시간이였다.
아래는 이번에 사이트 주소와 관련 블로그.
- 사이트 주소
http://www.wanderer99.com/ - 벨로그 프로젝트 설명
https://velog.io/@ysong0504/%ED%95%AD%ED%95%B4-99-2%EA%B8%B0-1%EC%B0%A8-%EB%AF%B8%EB%8B%88-%ED%94%84%EB%A1%9C%EC%A0%9D%ED%8A%B8
2. JWT vs Session vs Cookie
프로젝트가 끝나면 꼭 한번 정리하고싶었던 개념들, 오늘에서야 남겨본다. 1111
쿠키/세션/JWT를 사용하는 이유
HTTP 프로토콜의 특징
-
Connectionless
클라이언트와 서버가 요청과 응답을 한번 주고받으면 연결을 끊어버리는 특징
예) request & response 후 연결이 끊긴다. -
Stateless
위처럼 통신이 끊긴다면 상태 정보 역시 유지되지않는다. 즉, 로그인후 다른 페이지로 이동 시
다시 로그인을 해줘야되는 상황이 발생
인증 방식
1. 쿠키
특징
- key와 value 형식으로 클라이언트에 저장되는 데이터
- 인증 유효 시간을 설정할 수 있으며 해당 시간동안은 클라이언트 종료 후에도 유지
- 한번 쿠키에 저장하면 다음 요청 시에도 쿠키에 담긴 정보를 이용해 참조 가능
문제점
- 보안에 취약함
-사용자 인증 정보가 클라이언트에 저장됨으로 http 요청을 탈취당할 경우 사용자 정보를 빼앗길 수 있음
그러므로! 보안과는 상관없는 장바구니 혹은 자동로그인 설정 등에 이용 가능
2. 세션
특징
- 쿠키 기반이지만 쿠키와는 다르게 인증 정보를 클라이언트가 아닌 서버에 저장 및 관리
- 클라이언트 구분을 위해 서버는 각 클라이언트마다 세션ID를 부여하며 클라이언트가 종료될 때까지 유지
- 쿠키보다 보안이 좋다구..
문제점
- 세션 하이재킹 문제가 있어 유효시간을 만들어 예방 가능
- 세션 저장소를 서버에서 관리하므로 사용자가 많아질 시 서버 과부화 (동시 접속자 많을 수록 no good~)
세션 하이재킹이란, 사용자의 인증 작업이 완료되면 공격자가 해당 세션을 가로채 통신을 하는 행위!
3. 토큰 (JWT)
특징
- 인증에 필요한 정보들을 암호화시킨 토큰
- 세션처럼 토큰자체를 쿠키에 담을 수도 있고 HTTP헤더에 담아 보낼수도 있다.
- 3가지 요소로 구성되어있다.
Header : 3가지 요소를 암호화할 알고리즘같은 옵션이 들어간다.
payload: 유저의 고유 ID 등 인증한 필요한 정보가 들어간다.
Verify Signature: 위 2개와 Secret Key가 더해져 암호화된다. - Header와 payload는 누구나 디코딩이 가능하기에 보안이 필요한 정보는 넣지 않는다. 하지만
verify signature를 복호화하기 위해서는 Secret Key가 필요하다. - 세션처럼 저장소 관리가 필요하지않고 발급한 토큰이 클라이언트에게 전송 후 검증하는 과정만 있으면 된다.
문제점
- 토큰을 탈취당하면 유효시간이 끝나기도 전에 탈취자가 악의적으로 사용할 수 있음..
- 이것은 Refresh Token (Token 새로 발급)으로 예방 가능!
참고 출처 https://velog.io/@stampid/%EC%BF%A0%ED%82%A4-%EC%84%B8%EC%85%98-%EA%B7%B8%EB%A6%AC%EA%B3%A0-JWT
3. SSR vs CSR
프로젝트가 끝나면 꼭 한번 정리하고싶었던 개념들, 오늘에서야 남겨본다. 2222
렌더링이란,
서버로 부터 요청해서 받은 내용을 브라우저 화면에 출력하는 것
SSR(Server-Side Rendering)
특징
- 페이지 이동 시마다 새로운 페이지를 요청한다.
- 모든 template은 서버 연산을 통해서 렌더링 후 완성된 페이지로 응답.
장점
- SEO 최적화
- 첫 렌더링된 html를 클라이언트에 전달해주므로 초기 로딩 속도를 줄일 수 있다.
- 자바스크립트을 통한 렌더링 작업이 완료되기 전에 사용자가 사이트 컨텐츠를 이용할 수 있다.
단점
- 프로젝트의 복잡도
- 페이지 요청마다 새로고침이 발생하므로
페이지 이동시 화면 깜빡거림
서버 렌더링에 따른 부하 발생...(후..)
CSR(Client-Side Rendering)
특징
- 클라이언트에서 렌더링하는 방식
장점
- 첫 요청 시 전체 페이지가 아닌 특정 위치만 불러오기 때문에 빠른 상호작용을 기대할 수 있다.
- 필요한 부분만 새로고침없이 서버로 받아 화면을 갱신한다.
단점
- 초기 구동 속도가 느리다. (CSR이 될 때까지 사용자는 출력 전 화면을 봐야한다..)
- SEO 노 굳~
4. 느낀점 (첫 프로젝트를 마무리하며..)
3일이란 짧은 시간동안 팀원들과의 어색함도 사라지기 전에 하나의 프로젝트를 마무리했다는게 신기하다.
프로젝트가 끝나 후련하지만 지금 팀원들과 헤어지고 새로운 팀원들을 만난다는게 초큼 섭섭하긴 하다.
그래도 항해99가 진행되는 동안에는 같이 승선해 있는 거니까 나중에 팀이 달라져도
계속해서 서로 도움을 줄 수 있는 관계가 되었으면 좋겠다!
오늘 생각보다 프로젝트가 일찍 마무리되었는데 블로그랑 깃허브 등 이것저것 밀어왔던 것들을
정리하다보니 시간이 훅 갔다.
내일은 각자의 프로젝트에 대한 피어리뷰가 있다는데 어떤 분들을 만날지 궁금하다.
많이 배울 수 있는 시간이 되면 좋겠다.
오늘도 고생많았다! 내일도 열심히 개발하쟈! 불코!
