2022_03_10 SIL(항해 4일차)

• 목차
1.   회고
2.   배운내용
3.   오늘의 궁금 중???

 

 

1. 회고

방금 프로젝트 배포를 마쳤다,, 결국 마이페이지의 기능은 구현 실패했다.. 잠시 후 있을 회고 멘토링에서 문제점을 지적 받겠지만 우선적으로 내가 생각한 실패 원인에 대해서 정리해보고자한다.

 

첫 번째 깃헙

이 깃헙이 가장 중요한 요소인걸 항해가 시작하기 전에 얼추 듣고 있어서 알았지만, 이렇게 나의 발목 발목을 잡을줄은 꿈에도 몰랐다..

아직도 사실 과정이 잘 이해가 되지 않는다. 그래도 현재님이 알려주신 소스트리를 잘 이용해서 티키타카를 야매(?)  느낌으로 사용을 해서 어찌어찌 진행했다.. 과연 완전히 이해하는 날이 올까?,, ㅋㅋㅋ

 

두 번째 신뢰

나는 참 사람 말을 잘 듣는게 문제다.. 그래서 처음 발제해서 서비스 만들기를 할 떄 제시한 수업을 부분적으로만 참고해서 진행하면 된다고 말해주셨지만,, 전혀 ,, 알 수 가 없었다. 앞 내용을 전혀 알지 못하는 상황에서 그 기술만 쏙 뺴와서 사용하기란,, 말이 안된다. ㅋㅋㅋ 역시 쉬운건 없다.

 

세 번째 조급함

나는 너무 급하다.. 너무 너무 급해서,, 잘 못 본다.. 뭘 나의 이상한 코드를 ㅎㅎㅎㅎ,, 오픈 소스도 분명 차근차근 보면 알 수 있는데 급한 나머지 대충대충 ,, 난 개발 초짜다,, 자꾸 망각하지 말자,

 

일단 참회는 여기까지만 하고,,, 이번 미니프로젝트 우리조가 구현한 프로젝트를 살펴보자!  (바쁘다 바뻐 현대사회;;)

---

 

항해 99 6기 A반 8조 깃헙:  https://github.com/Gazuaaaaaa/Gazuaaaaa

유튜브 url:  https://www.youtube.com/watch?v=9kSfp-Myo4c

우리 조의 다음 사이트 크롤링 데이터를 가지고 매수와 매도를 가상으로 해 볼 수 있는 서비스이다. 물론 매수 매도를 구현하지 못했다,,

다행히 크롤링은 내가 맡아서 빨리 넘겼지만,, 이걸 서버와 클라이언트의 티키타카로 제대로된 구현을 못해서 너무 아쉬운 마음이다.

뭐 여기서 끝이 아니라 앞으로 더 노력해서,, 성장의 밑거름으로 삼아야지 ( 아쉬운 마음은 어쩔 수 가 없다ㅠㅠ)

 

우리 조원분들이 너무 도움을 많이 주셔서 뭔가 개발자로서 첫 단추를 잘꿴 기분이다. 항해 끝에 모두 현업에서 웃으면 만날날을 기대해 본다!

앞으로 일정은

내일 발제를 시작으로 다음주 목(3월 17일) 알고리즘테스트까지 알고리즘 공부를 계속 진행할 듯 하다,,

 

이제부터 진짜 몰입 시작이니깐 ! 제대로 알차게 공부해보자 !

---

 

2. 배운내용

 

이번 프로젝트를 진행하면서 배우게된 JWT에 대해 정리를 좀 해보려고 한다.

 

우리가 이번 미니프로젝트를 하면서 구현해야할 과제는 mainPage, myPage, loginPage, joinPage  총 4섹션을 만들어야 했다.

그 중 필수 사항에 JWT 인증 방식으로 로그인 페이지를 구현해야 했고, 과연 어떻게 이 기능을 가지고 회원 개개인이 관리 되는지 살펴보았다.

우선 JWT를 짧게 설명하자면 JSON Web Token의 줄임말로, JSON 객체를 사용해 정보를 안정성 있게 전달하는 웹표준이라고 한다.

만약 서비스 사용자가 로그인을 하면 서버에서 회원임을 인증하는 정보를 암호화 된 token을 넘겨주고, 이후 해당 회원만 접근할 수 있게 하는 서비스 영역에서 신분을 확인하는데 쓰이는 것이다.

웹서비스에서 JWT가 인증되는 과정을 살펴보면 다음과 같다.(이미지를 참고하면서 보면 더 쉽게 이해 가능)

JWT 인증 과정

1. 사용자가 로그인을 한다.

2. 서버에서는 계정정보를 읽어 사용자를 확인 후, 사용자의 고유한 ID값을 부여한 후, 기타 정보와 함께 Payload에 넣는다.

3. JWT 토큰의 유효기간을 설정한다.

4. 암호화할 SECRET KEY를 이용해 ACCESS TOKEN을 발급한다.

5. 사용자는 Access Token을 받아 저장한 후, 인증이 필요한 요청마다 토큰을 헤더에 실어 보낸다.

6. 서버에서는 해당 토큰의 Verify Signature를 SECRET KEY로 복호화한 후, 조작 여부, 유효기간을 확인한다.

7. 검증이 완료된다면, Payload를 디코딩하여 사용자의 ID에 맞는 데이터를 가져온다.

쉽게 알아보는 서버 인증 1편(세션/쿠키 , JWT) 그랩의 블로그

쉽게 알아보는 서버 인증 1편(세션/쿠키 , JWT)

이렇게 JWT 의 인증과정은 이루어진다. 이젠 JWT의 장단점에 대해서 살펴보자!🧐

장점

이 방식이 전에 존재했던 인증방식들에 비해 장점은 우선 간편하다는 것이다. 세션/쿠키는 별도의 저장소를 두고 관리하기 때문에 추가적으로 저장소의 관리가 필요하다. 그에 반해 JWT는 발급한 후 검증만 하면 되기 때문에 추가 저장소가 필요 없고 Stateless 한 서버를 만든데 강점을 가지고 있다. 이는 서버를 확장하거나 유지, 보수 하는데 유리하다. 그리고 확장성이 뛰어나서 토큰을 기반으로 하는 다른 인증 시스템에도 접근이 가능하다.

단점

하지만 이에 반해 단점도 존재한다고,, 이미 발급된  JWT에 대해서는 돌이킬 수 없다. 세션/쿠키의 경우 만일 쿠키가 악의적으로 이용된다면 해당 세션을 지워버리면 되지만, 한번 발급된 JWT 는 발급시점 이후 유효기간이 만료될 때 까지 계속 사용해야한다. 따라서 악의적으로 사용이 될 수도 있다고 한다.ㄷㄷㄷ

물론 해결책은 기존의 Access Token의 유효기간을 짧게 설정하고 Refresh Token 이라는 새로운 토큰을 발급한다. 그렇게 되면 Accsess Token을 탈취 당해도 상대적으로 피해를 줄일 수 있다고,,(그래도 피해는 있다는 말이겠지?? ㄷㄷㄷㄷ)

그리고 Payload 정보가 제한적이다. 이 Payload는 따로 암호화되지 않기 때문에 디코딩하면 누구나 정보를 확인할 수 있다. 따라서 서비스 이용자의 중요한 정보는 payload에 담길 수 없다. 그리고 마지막으로 JWT의 길이가 문제이다. 앞선 세션/쿠키 방식에 비해 JWT의 길이는 너무 길다. 그래서 인증이 필요한 요청이 많아질수록 서버의 자원낭비가 발생한다.

 

이번 미니프로젝트를 통해 JWT 인증방식으로 로그인 기능을 구현했는데, 다음에 기회가 생긴다면 세션/쿠키 방식으로도 인증방식을 구현해 봐야겠다.

---

UTF -8 이란? url : https://namu.wiki/w/UTF-8

 

3. 오늘의 궁금 중???

UTF-8은 가장 많이 사용되는 가변 길이 유니코드 인코딩이다. 켄 톰슨과 롭 파이크(Go 언어를 만든 사람)가 만들었다. UTF-8이란 말은 Unicode Transformation Format - 8bit에서 유래했다고.

 

4일동안 로그인과 회원가입 페이지를 구현하면서 참고영상으로 준 강의 내용 중 파이썬 3 이상에서는 UTF -8 로 자동 디코딩 된다라고, 하는 구절에서 과연 UTF-8 이 무엇일까?.. 라는 궁금증이 생겼다..

위의 설명처럼 인코딩이라고 나와 있는데 여기서 또 정확히 인코딩 혹은 디코딩이 무엇이냐?

위의 이미지를 보면 확실히 개념이 이해될 것이다. 갑자기 저 UTF-8이 궁금해진 이유는, 오늘 서비스 배포를 위해 서버에 올려서 배포를 했는데, 갑자기 특정 부분의 기능이 구현이 안됐다. 나중에 찾아보니 일전에 파이썬 3 에서 제공해준다던 UTF-8 decode 코드를 지운 것이 문제라는 것을 알고 다시 코드를 입력하고 배포하니 문제없이 잘 구현이 되었다.(나중에 우리와 같은 문제 해결을 하기 위해 더 검색을 해보았는데, 아마 PyJWT 파일을 다운그레이드 하는 방법도 있었다.)

 

 

 

 

하 어려워 너무ㅜㅜ