2주차 멘토링 노트
[발단]
base.html을 작성
→ base.html 에서 username을 출력해야 하는 부분이 있었다 (navbar 요소)
→ username을 기존처럼 request.user.username으로 가져오려고 하니 문제가 발생
test_02 계정으로 로그인했으나 username은 admin으로 출력되거나(캐싱된 데이터) 아무것도 안뜨는 문제 발생
→ user 정보를 받아올 수 없어 어떻게 처리해야하는지 고민하던 중 access token과 refresh token 처리에 대해서도 고민하게 됨
→ 그 와중에 프론트 세션이 있어 참여했더니 access token은 메모리로 다루고, refresh token은 http-only 설정된 쿠키에 저장을 하라고 함
→ 기존에 작성한 코드는 access token과 refresh token 모두 로컬 스토리지에 저장하는 방식인데, 로컬 스토리지는 xss 보안 취약점이 있어 사용을 지양하라고 하니 혼란이 옴
즉, 정리하자면
행 클라이언트 서버
1 | 로그인 페이지에서 로그인 정보를 넘김 | |
2 | 유저 정보 검증 | |
3 | 토큰 발급 후 refresh는 DB에 저장 | |
4 | 토큰을 클라이언트에 전달 (정확히는 access 만) | |
refresh는 http-only 설정된 쿠키에 넣고 | ||
access는 body에 담아서 전달 | ||
5 | access 코드를 메모리(변수) 저장 | |
6 | <- | |
ⓐ intercept해서 access 토큰 검증 (TokenVerifyView 날려라 이걸 먼저 하고 본 요청을 해라) | ||
ⓑ access 토큰이 만료된 경우 refresh 토큰 검증 | ||
ⓒ-1 ⓑ에서 refresh 토큰이 유효할 경우: token-refresh 요청 | ||
ⓒ-2 ⓑ에서 refresh 토큰이 만료됐을 경우: 로그인 페이지로 이동하도록 |
GET을 제외한 요청마다 headers - bearer 에 access 코드를 포함한 요청을 보내면 | | | 7 | | 서버에서 요청에 맞는 응답을 준다 | | 8 | 그리고 그 응답가지고 프론트에서 잘 보여준다 | |
[의견 취합을 해야하는 부분]
① 8번 행: 이 처리를 파이썬 Django view에서 하고 context에 담아서 render 하자 [<- 관님 의견] 아니면 기존에 작성해둔 js 코드가 있으니 이걸 활용하자 [<- 이건 정해진 의견]
[튜터님께 물어봐야 하는 것]
① 6번 행: 이렇게 진행해도 괜찮을지
- refresh 토큰 검증도 TokenVerify를 이용하면 될지, 아니면 TokenRefreshView 를 사용하면 될지
② TokenVerify를 제외하고 추가로 토큰 검증을 하는 과정이 필요한지
→ 프론트에서 엑세스코드 디코딩하여 페이로드의 유효기간을 확인해서 현재시간과 비교후 점검후 곧바로 재발급하는 로직으로 하면 서버에서 할 필요가 없는것 같은데 맞는가?
→ 서버에서도 해야 하는가? (사실 서버에서 해주는 게 TokenVerify가 맞는데, 여기에 더해서 추가로 해줘야 하는가?)
③ access 토큰을 메모리(변수) 저장을 했을 때 과연 다른 함수에서도 사용할 수 있을 것인가
①, ②, ③ 튜터님: 클라이언트한테 access와 refresh 둘 다 보내놔라 (되게만 해라)
① 추가 질문: 장고 미들웨어에서 알아서 해준다
① 추가 질문2: 선택 사항이다
④ refresh 토큰을 http-only 설정된 쿠키에 넣는다는데 넣는 코드는 알겠는데 이걸 꺼내쓸려면 어떻게 해야하는 것인가 즉, 꺼내 쓰는 주체는 서버인건 알겠지만 어떻게 사용하느냐를 모르겠다 클라이언트에서 refresh token을 가지고 token-refresh 요청을 보내야 하는데 이 요청 자체를 클라이언트에서 못하는 것인지, 못한다면 서버에서 해주는 것인지, 아니면 할 수 있으면 어떻게 하는 것인지
④ 튜터님: 직접 쿠키 살펴봐라
refresh를 http-only 설정한 쿠키에 넣으면 볼 수가 없다.
따라서 클라이언트 access token 만료되면 서버에서 쿠키 읽어서 직접 발급해줘야 하는데, 이거 처리하는 미들웨어 별도로 만들어서 적용해야 한다.
차피 xss 공격 같은거 안받을 거니까 나중에 해라. 일단 보안 신경쓰지 말고 구현부터 해라
⑤ 의견 취합 항목 ①에 대해서 튜터님께 조언 듣기
⑤ 튜터님: 나중에 프로젝트 분리(그니까, 프론트 같은 경우 python과 독립된 상태여도)를 생각하면 JS로 작성하는 것이 낫다.
추가 질문: async - await, ajax 어떤 거 쓸지 의논하고 정하긴 했는데, 특정 상황에서 다른 거 쓰는 이런 경우가 있나요?
답변: 원래 ajax 쓰다가 이게 프론트 개발자들이 보기에 안이쁘고 jQuery 안쓰기 시작해갖고 axios를 사용하기 시작했다. 근데 이것도 쓰다 보니까 불편해갖고 간편하게 작성할 수 있는 async-await으로 트랜드가 바꼈다. 셋 다 비동기 처리/서버와 통신/요청과 응답하는 구조 다 같으니까 원하는거, 결정한 거 써라. JS async - await 로 api 요청 보내고 처리하도록 작성해라.
추가 질문: 계획 세워둔 거 보시고서 앞으로 진행 방향 좀 짚어주실 수 있느냐
답변: 우선 주요 기능을 팀 내에서 결정을 하고, 그 기능이 동작하는 페이지를 먼저 배포를 해서, 그러니까 버전 1 배포를 하고 동작 테스트까지 완료를 해라. 그 상태에서 필요한 기능들을 추가해가면서 배포하고 추가하고 배포하고를 반복해라. 지속 가능한 개발을 추구해라.
'프로젝트' 카테고리의 다른 글
[TIL] 20240527 71일차 (0) | 2024.05.27 |
---|---|
[TIL] 20240524 70일차 (0) | 2024.05.24 |
[TIL] 20240523 69일차 (0) | 2024.05.23 |
[TIL] 20240522 68일차 (0) | 2024.05.22 |
[TIL] 20240521 67일차 (0) | 2024.05.21 |