(노드 숙련편 개인 과제중)
회원가입과 로그인 API는 만들었다. 하지만 기존의 API들을 새롭게 수정된 요구사항대로 손보고 MongoDB에서 MySQL로 옮긴 데이터베이스에 맞게 코드를 수정하는 과정에서 시간이 많이 갔다.
댓글 관련 API들은 수정을 끝냈고 내일 게시글 관련한 것들만 손 보면 되는데 여기는 새롭게 만들어야 할 API가 두 개 더 있어서 한 두 시간만에 완성하진 못할 것 같다. 사용자 인증 방식도 쿠키와 jwt 토큰 관련해서 대거 재검토에 들어가야 하겠고. 아무래도 하는 데까지만 하고 제출한 후에, 시간이 지나더라도 이어서 완성하도록 해야겠다.
- 쿠키와 세션, jwt 토큰에 대해 대략 이해했다. 일단 자세한 설명은 생략하고, 서버가 클라이언트에게 줄 때는 응답 헤더의 Set-Cookie 항목에 JWT 토큰 방식으로 발급한 accessToken과 refreshToken을 담아서 (쿠키로) 전달한다. 반대로 클라이언트가 서버에게 로그인 인증이 필요한 요청을 할 때는 요청 헤더의 Authorization 항목에 (서버로부터 발급받은) accessToken을 담아 보낸다. http가 사용하는 인증 방식이 Bearer 인증 방식이라 Authorization 헤더로 “Bearer xxx.yyy.zzz”이렇게 보내는 것이다.
- 엇 잠깐만… 서버가 왜 굳이 refreshToken까지 보내지? 이건 서버측에서만 들고 있다가 accessToken을 재발급할 때 써야 하는 것 아닌가.
- 일단 로그인을 해서 사용자 자신을 ‘인가’받아야 하는 상황이고, 마찬가지로 이미 accessToken을 들고 있다는 것은 한 번의 ‘인증(로그인)’을 마쳤다는 것일 텐데 왜 ‘Bearer(token) Authentication(인증)’이라고 하는 걸까? 그러면서 왜 헤더에는 또 Authorization(인가) 항목이라고 보내고..?
- 어제 express.urlencoded()에 대해 알아보면서 application/x-www-form-urlencoded 타입으로 요청이 들어올 때 이걸 해석하는 용도라고 이해했었다. 오늘 옆 팀 분과 얘기하다가 이 x-www-form-urlencoded라는 게 어떻게 프론트에서 가공되면 이렇게 생기게 되는 건지를 알게 되었다. 바로 <form> 태그 안에서 전달된 정보들인 경우 이 형식으로 전달되게 되는 것이었다..! 그래서 이름이 x-www-form-urlencoded였던 것이고..!
- 해결한 에러가 3개, 에러가 아니지만 해결한 문제가 길게 2개 쌓였다. 정리할 거 많다…
TIL을 어떻게 써야 하는가, 왜 써야 하는가에 대한 짧은 특강을 들었다. 공감을 많이 하였지만, 글 쓰는 과중함에 대한 부담은 덜어지지 않았다. 어떻게 ‘정리 부채’, ‘노트 부채’가 쌓이지 않도록 최대한 짧은 시간만 들여서 정리하고 기록해나갈 것인가. 꾸준한 연습으로 글 쓰는 것 자체가 익숙해져야만 하는가. 생각 정리라는 것이 빨라질 수가 있는가. 오래된 고민이다.
Uploaded by N2T