PoppyMail📬 개발일지

✔️부제 : Simple JWT를 사용한 로그인 환경 구성

기존에 PyJWT 라이브러리를 사용한 코드를 Simple JWT 라이브러리를 사용하도록 수정하였다.
머릿속에서는 원할하게 그려지던 그림이 직접 코드로 작성하려고 하니 막히는 부분이 많았고, 하루종일 생각을 하며 구현하였다.

✔️Simple JWT 라이브러리 사용 이유

맨 처음에는 JWT 생성만을 생각하여 PyJWT를 사용하였다. 그러나 PyJWT의 경우 정말 JWT 생성만을 도와주는 라이브러리여서 django-rest-framework에서 JWT 인증 방식으로 사용하기 위해서는 기존의 인증 클래스를 상속받아 새로운 클래스를 작성해줘야했다. 찾아보니 Simple JWT라는 라이브러리가 있었고 해당 라이브러리의 문서와 코드를 보니 django-rest-framework에서 쉽게 사용할 수 있도록 JWT와 인증 관련 코드를 모두 작성해줘서 그대로 가져다 쓰기만 하면 되었다. 인증을 직접 구현하는 것도 의미있겠지만 현 시점에서는 빨리 코드를 작성하여야 했기 때문에 SimpleJWT를 사용했다.

할 일 비교
Simple JWT 사용할 경우 : User 모델 확장(django.contrib.auth.models의 User 상속받아 사용) + 로그인 로직 처리
PyJWT 사용할 경우 : User 모델 확장(위와 동일) + JWT 관련(create, refresh 등) + 로그인 로직 처리 + JWT 인증 처리
➡️ 따라서 Simple JWT가 더 효율적임

✔️로그인 구성 흐름

ㄱ. (프론트 → 서버) 프론트에서 카카오에게 사용자 정보를 요청하기 위한 access_token 전달해줌
ㄴ. (서버 → 카카오) 전달받은 access_token으로 서버에서 카카오에 사용자 정보 POST 요청함
ㄷ. (카카오 → 서버) 카카오로부터 전달받은 사용자 정보로 우리 DB에 등록되어 있는 유저인지 체크
ㄷ-1. 우리 DB에 등록된 유저인 경우
ㄷ-2. 신규 유저인 경우
→ 전달받은 카카오 회원번호를 username으로, password는 서버에서 자체 설정하여 User(auth.models) 객체 생성
ㄹ. (서버 → 프론트) Simple JWT의 토큰 생성 로직으로 생성된 토큰을 프론트에게 전달
ㄹ-1. 신규 유저인 경우 사용자 추가 정보 입력받아 AppUser(User 모델 확장한 것) 객체 생성
ㅁ. 로그인 최종 완료!

✔️개발 이슈⭐️

아래의 이슈들은 simple-jwt 라이브러리를 사용해 로그인 기능을 구현하면서 그때그때 생긴 이슈들을 순서대로 작성해놓은 것이어서 개발의 흐름과 동일함

#1 User 모델 커스터마이징

simple-jwt 라이브러리에서는 token 생성 시 django.auth.models에서 기본 제공하는 User를 바탕으로 사용자가 입력한 username, password에 해당하는 유저가 있는지 확인해서 토큰을 제공해줌

# simple-jwt의 serializers.py
from django.contrib.auth import authenticate, get_user_model

class TokenObtainSerializer(serializers.Serializer):
    username_field = get_user_model().USERNAME_FIELD
    . . .

따라서 User 모델을 사용해야하고, 우리 서비스에서는 추가로 저장해야하는 값들이 존재했기 때문에 User 모델을 기반으로 커스터마이징을 해줘야 했음
Django 공식문서 를 보니 인증 커스터마이징의 경우
A. 기존의 User 모델 확장 (채택!)
B. 기존의 User 모델 사용하지 않고 아예 다른 모델로 대체하기
2가지 방안이 존재했는데, simple-jwt 라이브러리에서는 기존의 User 모델을 기반으로 토큰을 생성하기 때문에 A 방안을 채택함

#2 토큰 생성을 어떻게 처리할 것인가?

1. 상황
우리 서비스는 카카오 로그인만 가능하도록 하기 위해 사용자가 직접 username, password를 작성하지 않아도 되는 구조였음(즉 카카오로 로그인하기 버튼 클릭하면 바로 로그인 처리되는 구조)
만약 username, password를 입력하는 구조였다면, 바로 simple-jwt 라이브러리에서 제공해주는 POST api/token/ 를 프론트에서 요청하면 되는 것이었음
하지만 로그인 요청 시 DB에 사용자 저장 & 토큰 생성까지 한번에 처리해줘야 했기 때문에 토큰 생성 요청을 어떻게 처리해야할지 고민함

2. 해결방안
생각1) POST api/token/ 서버에서 직접 요청
수행 방법 :
Requests 라이브러리를 사용해서 수행 가능함

# 토큰 생성 (simple-jwt)
     def createJWT(self, user):
         url = 'https://poppymail.shop/api/token/'  
         payload = {'username': user.username, 'password': '{임의의 값}'}
         return requests.post(url, json=payload)

결론 :
로컬에서 테스트할 때는 정상적으로 잘 작동되었음
하지만 배포 후 테스트할 때는 timeout이 남
(관련 내용 확인➡️PoppyMail 개발일지 - 배포 후 테스트)

생각2) POST 요청하지 않고, 토큰 생성 로직으로 바로 연결 (채택!)
관련 내용 확인➡️PoppyMail 개발일지 - 배포 후 테스트

simple-jwt의 토큰 생성 로직에 대한 github 코드를 보니 해당 함수를 이용해 토큰을 생성하는 것이었으므로, 해당 함수를 사용하도록 하였음(import 했으니까 사용가능함! - simple-jwt에 구현되어 있는 함수이니까) / 라이브러리를 사용할 때도 동작 원리를 이해하니(함수 호출 등) 필요할 때 그 부분을 직접 활용할 수 있는 것 같아 뿌듯했다. 사용하는 라이브러리의 원리를 잘 이용하는 것이 중요함을 느꼈다.

#3. 로그인/로그아웃/탈퇴 로직을 어떻게 처리할 것인가?

1. 상황 및 깨달음
생각해보니 먼저 큰 틀을 잡고 세부사항을 생각했어야 했는데 지금 나의 경우에는 세부사항인 token 생성부터 생각하다보니 세부 → 큰 틀을 생각하는데에 여러움이 있었던 것 같음. 즉 큰 틀인 로그인/로그아웃/탈퇴 구현 방안을 잡고 그 세부사항에서 token 인증 방식을 추가하면 되는 것이었음

2. 해결 방안
생각1) dj-rest-auth 라이브러리 사용하기 docs
장점 :
→ User 등록, 로그인/로그아웃, User model 반환 및 업데이트, 비밀번호 변경, e-mail로 비밀번호 변경, 소셜 로그인 인증 등의 다양한 기능 제공
단점 :
→ 우리 서비스의 로그인은 Id, PW 입력 방식이 아니므로 기존에 작성된 코드를 조금 변경해줘야 함
→ 우리 서비스에서 필요한 기능에 비해 과도한 기능을 제공해줌
따라서 해당 라이브러리의 코드는 소셜로그인(인증코드 얻기부터), 기존 로그인에 대한 로직이 완벽하게 짜여있으므로 중간에 커스터마이징을 하는 것이 더 번거롭다는 결정을 내림

생각2) 직접 로그인/로그아웃/탈퇴 로직 구현하기 (채택!)
로그아웃의 경우에는 그냥 토큰 처리만 해주면 되고, 탈퇴의 경우 User 모델만 삭제해주면 됨

class LoginView(APIView):  # 로그인
    permission_classes = [AllowAny]

    # 카카오톡에 사용자 정보 요청
    def getUserFromKakao(self, request):
        

    # DB에 있는지 판별 (auth_user)
    def checkUserInDB(self, kakao_user):


    # simple-JWT을 사용해 토큰 생성 해주는 역할 수행
    def createJWT(self, user):
       

    def post(self, request):
        

class AddUserInfoView(UpdateAPIView):  # 사용자 정보 추가 입력(업데이트)
    # 인증 & 허가 - JWTAuthentication, IsAuthenticated (기본 설정)

class LogoutView(APIView):  # 로그아웃
    # 인증 & 허가 - JWTAuthentication, IsAuthenticated (기본 설정)

class SignoutView(DestroyAPIView):  # 탈퇴
    # auth_user 삭제하면 -> AppUser, OutstandingToken, BlacklistedToken도 삭제됨 (서로 cascade로 설정되어 있음)
    # 인증 & 허가 - JWTAuthentication, IsAuthenticated (기본 설정)

위의 코드 구조로 views.py를 작성하여 처리함

#4 사용자 정보 추가 입력 완료하고 페이지 뒤로가기에서 또 입력한 경우에 대한 처리

1. 상황
우리 서비스에서 사용자 최초 로그인 시 추가로 회원 정보를 입력해야 함
이때 웹 페이지이다보니 사용자가 추가 입력 완료하고 뒤로 가기 눌러서 다시 회원 정보를 입력하는 상황이 발생할 수 있음

2. 해결방안

생각) PATCH로 설정하기 (채택!)
사용자 정보 추가 저장이라는 생각에 사로잡혀 처음에는 POST로만 생각했었는데, 생각해보니 미리 해당 모델 객체를 생성해두고 UPDATE로 API 설정을 해두면 해결 가능한 것이었음
즉 변경하면 변경한대로 저장되게 하는 것이다! 이때 PUT과 PATCH가 있는데 원칙은 전체 항목을 모두 입력하는 것이지만 부분적인 업데이트로서 처리하기 위해 PATCH로 설정함

#5 우체통 고유키 값 필드에 unique=True를 설정할까말까?

1. 상황
우리 서비스에서는 개인마다 정해진 우체통 링크에 접속하면 아무나 편지를 작성할 수 있도록 구성함
이때 어떤 악의적인 사용자가 url을 변경하여 다른 사람의 편지에 막무가내로 편지를 작성할 상황이 벌어질 수 있음
실제로 익명 질문 서비스인 Ask의 경우 ask.kr/{사용자 id} 형태의 url에 접속하면 해당 사용자에게 질문을 작성할 수 있는데, 저 {사용자 id}만 바꿔서 요청하니 해당 id 값의 사용자에 대한 질문 작성 페이지로 이동이 되었음
이를 바탕으로 우리 서비스의 사용자가 원치 않는 편지를 받지 않게 하기 위해 url 구성에 대해 고민함

2. 고민 방안
생각1) 우체통 키 값 필드에 unique=True 설정할 경우
URL 형태 : poppymail/{secret_key}
장점 : 비밀 키 값 겹칠 확률 0
단점 : 비밀 키 값이 8자리이고, char 타입이므로 매번 생성할 때마다 해당 값이 이미 존재하는지 우체통 테이블에서 확인해야 하므로 db에 부담이 클 것임

생각2) unique=True 설정 X (채택!)
URL 형태 : poppymail/<int:pk>/?key={key}
장점 : 생각1의 단점이 보완됨
단점 : URL의 형태에서처럼 전달된 pk에 해당하는 우체통의 key값과 전달된 key값이 일치하는지 처리해줘야 함

결론) 생각1보다는 key 값을 비교하는 로직으로 처리하는게 더 효율적일 것 같아서 생각2를 채택함 !