구현 목표 기간 : 6월 26일~ 7월 2일
어떤 인증 방법이 django와 poko에 더 적합한지 구현과정을 통해 알아보려고 합니다.

6월 26일

1. dj_rest_auth로 빠른 로그인구현 완료

2. 인증 시 JWT 적용을 위해 django simplejwt 설치하였으나 로그인 이후 key token만 발행되고 acess token과 refresh token은 발급되지 않음을 확인.

3. 세션은 장고 기본인증 방법으로 특별한 구현이 필요하지않음.

6월 27일

1. token의 원리를 파악하기 위해 생활코딩 JWT 수강하며 session과 token 개념과 원리 숙지

2. 궁금증:
   생활코딩은 API 통신 시 JWT 인증을 선호함.
   참고 중인 다른 강의에서는 세션 인증을 선호함.
   Django 기본 인증은 세션 인증임.

3. 생각 정리:
   JWT는 사용자 정보가 포함되어 매번 요청 시 안전하지 않을 수 있다고 생각.
   세션 인증은 DB 리소스 부하가 있지만 보안 면에서 안전하다고 생각.
   JWT 토큰의 만료 시간을 짧게 설정하고 리프레시 토큰을 함께 사용하여 리소스 부하를 줄일 수 있음.

4. 최악의 경우 가정:
   세션: DB 과부하로 인한 데이터 손실 가능성.
   토큰: 토큰 탈취 시 시스템 접근 가능성으로 인한 개인정보 유출 및 불법 접근 위험.

5. 개인적인 결론: 토큰의 최악의 경우가 더 치명적이라 생각하며, 세션 인증의 DB 리소스 부하를 줄이기 위해 Redis를 고려.

6. 실행 계획:
   세션 인증: Django에서 기본 인증 방법을 복습.
   JWT: 오류 해결 시도.

6월 28일

1. 6월 26일에 확인 한 오류 보류(jwt)
   dj_rest_auth에서 두개 토큰이 발급되지 않은 이유에 대한 해결 참고

2. 세션키 쿠키가 브라우저에게 전달되는 과정을 잘못 이해한 것으로 비롯된 이슈
   Django Session Cookie 동작 오해풀기

7월 3일-5일

1. login-registration 컴포넌트 분리
   해당 글 참조

2. 로그인 UI및 API 구현 완료

• 403 csrf 토큰 에러
  csrf 정리

• 로그인 후 응답 상태 값 확인하기

  7월 7일

1. 6월 26일에 확인 한 오류 보류(jwt)
   dj_rest_auth에서 두개 토큰이 발급되지 않은 이유에 대한 해결 참고

2. Redis 사용

3. 3가지 인증방법에 대한 성능테스트 계획

7월 8일

1. 성능 테스트