09.18 1주차 회고록

1주차 프로젝트가 끝났다.

사람들이랑 밤 새워가며 코딩을 하는게 요리대회를 나갔을 때랑 비슷해서 학부생 때의 기억이 떠올라 좋았다. 학생으로 돌아간 느낌이 들었다는거지..

같은 시간, 다른 결과물을 보고 잘 하시는 분들이 정말 많으면서 동시에 많이 부족했음을 느꼈다.
그리고 정말 좋은 분들이 많이 계시는 걸 다시금 느낄 수 있었다.

---

완성 결과물 : 보고 또 보고

시간 안에 낼 수 있을 것이다. 라는 기대와는 달리 제출 시간을 넘겼다는게 아쉬웠다.
왜 이렇게 늦어졌을까 생각을 해봤다.

1. 깃을 써봤다고 처음부터 알려드렸던게 오히려 시간을 잡아먹지 않았나 생각이 든다.
5일의 시간 중 따져보면 깃으로 허비한 시간이 많았던 것 같다.
나도 잘 아는게 아닌데 팀원들한테 알려주고 에러가 나면 내가 고치는 상황이 반복됐고 이게 누적되어 팀 프로젝트에 영향을 미쳤으리라 생각된다.
오히려 진자로 템플릿을 나눈 시점부터 깃을 썼으면 어땠을까 싶다.

2. 역할 분배에 실패했다.
와이어 프레임을 짜고 역할을 분배하는데 있어서 어떻게 나누면 좋을지를 몰랐다.
결국 필수 기능 2개를 2명씩 나누는 걸로 했는데 역시 크게 나누는 것보다 조금 더 세세하게 나눴으면 좋았을 것 같다.
하지만.. 난 몰랐는걸..

jinja2

진자는 이번이 두번째로 써보는 기회였다.
템플릿을 나누면서 직접 코드를 넣어보니 어떻게 구성이 되는지 이해가 잘 됐다.
역시 백문이 불여일견, 백견이 불여일행 ㅎㅎ..

• Jinja 템플릿은 Python Flask 패키지에 내장된 Template 엔진으로 동적으로 변하는 웹페이지를 쉽게 구현할 수 있도록 도와주고.
• 고정적으로 출력되어야 할 서식 html 코드가 존재하고 동적으로 변해야할 자리는 Jinja2 문법으로 비워둔다. >> 이 부분에서 틀이 있고 재료를 넣어 만들어 간다고 느낀 것 같다.
• html 안에서 파이썬 코드를 작성할 수 있도록 해준다.

써보면서 느낀 것은 뭔가 도자기 틀이 있고 거기에 재료를 넣어 만들어 나가는 느낌이었다.
상세한 사용방법은 여기

---

계속 매달렸던 회원가입 문제

결론은 render_template에도 메서드를 걸어줘도 된다고 한다..
지금까지 보고 배운 것 중에서 메서드를 쓴 것을 본 적이 없었어서 당연히 쓰면 안되겠지 했는데 쓰고나서 에러가 발생하지 않으니 써도 되나..? 라고 의문을 가졌지 확신은 못했다.
결국 멘토분께 여쭤봤는데 써도 되는 거라고 하셔서 안도했다.😄

JWT를 이용한 로그인😂

웹 페이지에 로그인을 할 때 서버에선 내가 로그인을 하고 있다는 사실을 알고 있어야한다.

인증 Authentication
내가 이 사이트에 가입된 회원임을, 즉 특정 서비스에 일정 권한이 주어진 사용자임을 아이디와 패스워드를 통해 인증을 받는 것
인가 Authorization(권한부여)
인증을 받은 사용자가 이후 서비스 기능들을 사용할 때. 서비스 제공자가 (인증을 통해)이를 알아보고 기능을 사용할 수 있게 허가를 해주는 것

JWT(JSON Web Token)는 인가(Authorization)에 연관된 기술이다.

. 을 기준으로 세 부분으로 구분이 되는데,
차례대로 각각 header, payload, verifysignature(서명)로 구분된다.

header : 타입과 알고리즘으로 구성되어 있다. 타입 'JWT'는 고정값이고 알고리즘은 3번 서명값을 만드는데 사용 될 알고리즘이 지정된다. HS256 등 여러 암호화 방식 중 하나를 지정할 수 있다. JWT를 어떻게 검증하는가에 대한 내용을 담고 있다.
여기서 1번 헤더와 2번 페이로드, 서버에 감춰놓은 비밀 값 이 셋을 암호화 알고리즘에 넣고 돌리면 3번 서명값이 나오는 것이다.

payload : 이 토큰을 누가 누구에게 발급했는지, 언제까지 유효한지 등 서비스는 사용자에게 토큰을 통해 공개하기 원하는 내용을 서비스 측에서 원하는대로 담을 수 있다.
이렇게 토큰에 담긴 사용자 정보 등의 데이터를 Claim이라고 한다.

verify signature : 헤더와 페이로드를 합친 문자열을 서명한 값이다. 서명은 헤더의 alg에 정의된 알고리즘과 비밀 키를 이용해 성성하고 Base64 URL-Safe로 인코딩한다.

---

이 셋을 합치면 JWT가 완성된다.

장점 : 서버측 부하를 낮출 수 있고 능률적인 접근 권한 관리를 할 수 있다.

단점 : 서버에는 토큰을 보낸 사용자에 대한 정보가 없기 때문에 토큰이 탈취당한 경우 무효화 할 방법이 없다.

---

처음부터 로그인에 매달릴걸.. 코드를 붙여 넣은 것인데도 에러 때문에 꽤 오랜 시간이 걸렸다.
에러 메세지를 검색하고 시도해봐도 해결을 못 하고 제출 시간을 넘겼고 결국 주변 분들이 도와주셔서 해결 할 수 있었다.

디버그 모드를 적극 활용하기 -> 코드 하나하나 문제가 있는지 찍어볼 수 있었다.

API 😀

보다 쉽게 정리되어 있는 API 설명서

이번 프로젝트에서 API를 GET과 POST 방식으로만 구성했는데 이 외에도 더 있다는 것을 알게됐고,
사전 강의를 들으면서 모호했던 API 코드 부분을 계속 보고 어떤 순서로 작동이 되고 코드를 직접 짜보면서 이해가 좀 된 것 같다.
하지만 api에 대한 정의 부분은 잘 모르고 있던 터라 찾아보게 되었다.

현재 이해한 바로는 POST는 데이터를 수정하고 보낼 때 즉, 데이터에 변화를 줄 때 쓰는 것.
GET은 서버에서 가져온 데이터를 보기 위해 사용한다고 느꼈다.