3월 10일(JWT와 Jinja2를 사용한 미니프로젝트 시작)
팀원 3명과 태어나서 처음 들어보는 JWT, Jinja2를 사용하여 웹사이트를 만드는 것이 과제였다.
바로 다음날인 11일날 11시에 있을 기획 발표회를 위해 와이어프레임이라는 것을 배웠다.
와이어프레임이라는 것은 앞으로 만들 웹사이트의 골격이나 UI와 주기능을 그림이나 도형으로 제작한 다이어그램의 집합이라고 한다.
DB ERD모형이나 흐름을 보여주는 FlowChart는 사용해봤는데, 새롭게 들은 용어라서 신기했다.
결론적으로, 팀원과 함께 코딩 커뮤니티, 운동 매칭 사이트 등의 의견 중 정글에서 쓰일만한 배달음식 사람 매칭 사이트를 제작하기로 결정했다.
와이어프레임을 피그마라는 사이트를 통해 구상했다. 아키텍처, 기술적 도전 등을 종합적으로 구상하여 PPT 제작까지 마쳤다.
역할 분배에서 로그인부분에 대한 프론트 엔드와 JWT를 사용한 백엔드 구현을 담당했다.
프론트 엔드 구성을 위해 Bulma를 통해 구성하는데, 배경 Html하고 컨텐츠 내용 색이 다르게 보이는 문제가 있었다. 찾아보니 Bulma에서 다크모드를 지원 했기 때문이었고, 를 상단에 적용하므로서 밝은 버전의 모드를 강제 적용할 수 있었고, 팀원의 편의를 위해 해당내용을 공유 했다.
새벽 3시 퇴근길... 캠퍼스는 아름답다
3월 11일(JWT)
JWT 로그인 방식에 대해 학습했다. 유튜브로 대충 이해하고자 했고 다음 사이트가 유용했다.
https://www.youtube.com/watch?v=XXseiON9CV0&ab_channel=%EC%BD%94%EB%94%A9%EC%95%A0%ED%94%8C
로그인 토큰을 생성해서 인증을 하는데, 시크릿 키라는 값과 정보를 가진 태그를 혼합해서 토큰을 생성한다고 한다.
대강 이해와 보안성을 확인했고, 좀 더 자세히 공부하기위해 다음 사이트를 참고 했다. https://yeees.tistory.com/64 보면 알 수 있겠지만 해시를 통해(보통 sha256) 비밀번호를 인코딩만 가능한 단방향 암호화를 시키고 [헤더.페이로드.시그니처]을 base64형식으로 토큰을 생성하여 서버에 인증을 받고 통과되는 시스템이다.
간단히 사용자가 로그인하면 DB에서 해당 아이디와 비밀번호를 갖는 회원이 있는지 찾아서 서버에서 아이디와 토큰 만료 시간을 저장하는 JWT 토큰을 넘겨줌으로써 토큰을 가지고 쿠키에 저장하여 만료되기 전까지 API가 요청을 보낼 때마다 회원임을 확인할 수 있다고 보면된다.
세션은 세션 저장소로부터 세션 ID를 발급 받고 쿠키에 있는 세션을 확인하며 데이터를 주고 받는 반면, JWT는 토큰을 서버자체에서 발급 받고 바로 검증 하기 때문에
속도면에서 우수하고 서버에 부담이 줄어든다. 고로 로그인 시스템이 빨라지게 된다.
인터넷에 있는 정보를 통해 JWT시스템이 완성되었는데, 로그인은 되는데 토큰이 어떻게 생겼고 진짜로 토큰 형식의 정보로 처리를 하는지 궁금해졌다. 그래서 방법을 찾다가 팀원이 포스트맨이라는 백엔드 값 추출 프로그램을 통해 어떤 값이 표현되는지 알 수 있다고 했다. 바로 설치해서 써보았고 폼데이터 값을 입력하니 토큰값을 확인할 수 있었다.
JWT 토큰 디코딩 사이트에 접속하여 시크릿코드와 토큰값을 입력하니, 일치하는 시크릿코드와 토큰에서 보내는 id, pw값이 클라이언트가 입력한 값과 같음을 확인할 수 있었다. 궁금증 해결!
여기서 문제가 있다.사용자가 로그인 후 로그인 상태를 유지하려면 토큰값이 갱신이 되거나 유효시간이 되어도 문제가 없어야됩니다. 그러기 위해서는 리프레쉬 토큰이라는 것을 사용합니다. 본래의 엑세스 토큰은 5분정도로 짧게 유지하고 리프레쉬 토큰을 길게 설정하여 로그인을 유지한다고 합니다. 보안적으로도 해당 방식을 추천합니다.
간단히 탈취 상황도 알아보았는데,
엑세스 토큰이 탈취된다면?
리프레쉬 토큰이 없으므로 짧은 파기시간에 다가오면 자동으로 파기된다. 그래서 엑세스 토큰의 활성화 시간이 짧게 설정한다.
리프레쉬 토큰이 탈취된다면?
서버측의 검증 로직이 필요하다고 하다. DB에 각 사용자에 1대1로 맵핑되는 엑세스와 리프레쉬 토큰을 저장한다. 정상적인 사람은 엑세스토큰으로 접근해 DB의 엑세스 후 비교해서 값이 다르면 파기함.
근데 이건 너무 보안적이다. 그래서 일단 리프레쉬 토큰으로 로그인 정보를 유지해보도록 구현해 보았지만 시간적 부족으로 엑세스 토큰을 2일로 설정하여 개발했다.
번외)테스트를 하다가 로그인시 똑같은 비밀번호를 해싱했을때 똑같은 값이 DB에 저장되어 잘 못된 결과인줄 알았는데, 정상적인 작동이었다.
팀원들과 Git Hub를 만들어서 통합하는 작업을 수행했고, 그 과정에서 충돌을 대비한 브런치라는 기능을 사용했다. 리포지트리가 나한테 있었기 때문에 팀원이 준 브런치 내용을 검토해서 본 Git 프로젝트에 merge를 하면 합쳐진다. 브런치와 관련된 설명은 팀원이 Git Hub사이트를 통해 알려주었다.
코딩하는 중...
3월12일(Jinja2)
회원가입에 기반이 되는 비밀번호 확인과 형식적으로 적합한지 확인하는 유효성 검사 부분을 추가했다. 유효식을 구현하는게 제일 힘든 것 같다.
오늘 배운건 Jinja2의 원리이다. 팀원이 사용 방법과 이론을 설명해줬다. 로그인 쪽은 잘 쓰지 않지만 메인페이지 쪽은 많이 써서 중요했다.
Jinja2는 파이썬에서 잘 사용되는 템플릿 엔진이다. 내 프로젝트에서 사용하는 Flask에서 템플릿 엔진 중 하나라고 한다.
정적인 HTML을 동적인 데이터를 결합해서 웹페이즈를 생성한다. 템플릿 파일에 함수, 데이터를 함께 삽입해서 동적인 HTML을 생성한다.
보통 변수를 사용하기 위해 {{변수}}를 사용합니다. if문과 함께 쓴다면 지정된 조건에 부합하면 컨텐츠를 보여주고, 부합하지 않으면 보여주지 않게 설정하는 것도 가능하다.
그럼 Jinja2를 쓰는 이유가 무엇일까?
앞에서 말했다시피 원래는 클라이언트에서 차곡차곡 쌓는다. 근데, 서버에서 처음부터 조립해서 클라이언트로 보낸다. 이로 인해 첫화면 로딩속도가 빠르고 클라이언트의 부담이 적다. 보안적으로도 우수하다.
그러나 서버에서 조립하고 보내는 시간이 있다보니 중간 로딩이 길고, 서버에 부담이 간다는 단점이 있다.
협업을 하다보니 깃허브 충돌이 많이 발생했다. 모두 수정하느라 시간이 오래걸렸다.
3월13일(최종배포, nohup문제)
오늘은 최종 배포와 발표자료를 구성하여 13시에 있는 미니 프로젝트 발표회에서 발표를 해야한다.
스케줄링을 구현해보고자 노력했지만, 새 패키지에 배우지 않은 내용이라 일반 코드로 데드라인 처리를 하는 것으로 대체했다. 추가적으로 본인채팅에 초록색으로 강조하는 효과도 추가 했다.
PPT파일, 프로젝트 파일, URL, 깃허브 등을 팀원들과 함께 코드리뷰하며 최적화하여 최종 제출했다.
발표회를 진행하고 배포부분에서 문제가 있었었는데, 문제는 이러하다.
배포를 진행하면 SSH로 맥북에서 EC2로 연결을 하여 웹서비스를 개시한다. 근데, 맥북을 계속 켜둘 수가 없으니(맥북이 꺼지면 일정기간동안 동작이 없을시 SSH연결을 해제하고 그러면 웹서비스가 멈춘다)nohup이라는 명령어를 쓴다. '백그라운드에서 해당 프로그램을 계속 실행시켜라'와 같은 명령어이다. 이 명령어가 안되서 조사를 했다.
내 그룹이 만든 실시간 채팅시스템에는 Soketio라는 패키지를 사용한다. 근데 개발로 진행하니 개발환경으로 서버에 배포를 하면 보안문제로 nohup이 거부되는 문제가 있었다. 그래서 맨 아래 소켓 관련 세팅에 allo_unsafe_werkzeug=True를 추가해 보안성을 낮추는 대신 nohup을 사용할 수 있게 됐다. 원래는 eventlet이라는 패키지를 사용해서 보안을 유지하는게 좋은데, 빠른 정상화와 시간 부족 문제가 있어 해당 방법으로 간단히 해결했다.
우리팀이 썻던 프로젝트 구조도와 계획
이렇게 크래프톤 정글에서의 첫 미니프로젝트가 끝났다. 몇일정도 몇시간 밖에 잠을 못자고 하루종일 코딩하며 개발했지만, 팀원이 있기에 할 수 있었다. 다른 팀도 힘내서 하는 모습을 보니 자극 받아서 더 열심히 했다. 다음 주 부터 4주간 백준 알고리즘을 공부하고 컴퓨터 시스템에 대해 공부할 예정이다.
해당날 저녁에 회식으로 삼겹살을 먹어서 기운차리고 다시 시작하려한다.
삼겹살정도는 먹어야죠
정글의 연대기는 계속됩니다...
