DJANGO

DRF에서 JWT토큰 발급을 구현하려면 어떻게 해야할까?

document.jwt.png

DRF, Django에서 직접적으로 JWT토큰과 관련된 로직을 제공해주진 않지만 DRF공식문서 API Guide Authentication페이지에 JSON Web Token Authentication섹션을 보면 알 수 있듯이 DRF는 친절하게도 JWT토큰을 통한 인증을 구현하는데 djangorestframework-simplejwt라는 패키지를 권장한다.

simplejwt패키지를 사용하여 JWT토큰 발급하기

지금까지 알게된것은 그저 simplejwt라는 패키지를 통해서 JWT토큰 로직을 쉽게 구현할 수 있다는것 뿐이지만 놀랍게도 그게 다라는 것, 즉 JWT토큰을 구현하는데 필요한 준비는 다 했다고 말할 수 있다.

simplejwt의 <a href="https://django-rest-framework-simplejwt.readthedocs.io/en/latest/getting_started.html">Getting started섹션</a>을 보고 천천히 따라해보자

일단 당연한 절차인 패키지를 사용하기 위해 설치를 진행한다.

설치를 완료했다면 이제 simplejwt와 관련된 설정을 할 차례다.

일단 가장 먼저 settings.py INSTALLED_APPS에 <code class="inline-code">'rest_framework_simplejwt'</code>를 추가하고

simplejwt-installed-apps.png

DRF설정에서 DEFAULT_AUTHENTICATION_CLASSES로 아래와 같은 경로형태의 문자열을 추가하자

simplejwt-default-authentication-classes.png

일단은 DEFAULT_AUTHENTICATION_CLASSES라는 값에 대해 의미 그대로 기본 인증 클래스를 JWTAuthentication이라는 클래스로 설정했구나 라고 생각하고 다음 스텝으로 넘어가자

DEFAULT_AUTHENTICATION_CLASSES ??

그 다음은 simplejwt에서 제공하는 View들을 urls에 추가하는 단계이다.

simplejwt-urls.png

아마 Class형태의 View를 작성해봤다면 위 코드가 어떠한 동작을 가지게 되는지 간단하게 예상할 수 있을거라고 생각한다.

간단하게 설명하자면 '/api/token/' url로 클라이언트가 접근했을때 TokenObtainPairView라는 클래스 View의 요청한 HTTP method에 따른 메서드가 호출된다.

놀랍게도 DRF에서 JWT토큰 발급을 구현하는건 이 세 단계가 끝이다.

이제 실제로 사용해보면서 JWT토큰이 잘 생성되고 응답받을 수 있는지 확인해보자.

친절하게도 simplejwt문서 Getting started페이지의 Usage섹션을 보면 사용방법 또한 파악할 수 있다.

simplejwt-response-token.png

'/api/token/'경로로 POST method요청을 보낼때 HTTP Request Message Body에 인증을 진행할 유저의 아이디와 패스워드를 담아 보내기만 하면 된다.

postman-token-response.png

위와 같이 POST메서드를 통해 username과 password를 body에 담아서 HTTP Request Message를 서버에 전달했을때

HTTP Response로 생성된 refresh토큰과 access토큰이 있는걸 확인할 수 있다.

위 access토큰은 보기에는 굉장히 복잡한 문자열이지만 저 토큰만으로 request를 보낸 유저가 누구인지 판별할 수 있다.

만약 특정유저의 정보를 가져오는 기능이 있고 해당 기능은 특정 권한이 존재해야만 가능하다고 가정해보자

일단 접근한 유저의 권한을 파악하기 전에 먼저 어떤 유저가 접근했는지부터 알아야한다.

필자는 테스트를 위해 UserView를 따로 만들었고

UserView의 get method는 오직 테스트를 위한 목적으로 <code class="inline-code">request.user</code>만 출력하고 상태코드 200인 응답을 반환한다.

여기서 주목할 점은 <code class="inline-code">request.user</code>로 어떤 값이 출력되는것인가 이다.

아래와 같이 아무런 설정없이 request를 보내보면

postman-api-user-none-header.png

anonymoususer.png

<code class="inline-code">request.user</code>로 AnonymousUser라는 값이 출력되는걸 확인할 수 있다.

AnonymousUser는 의미 그대로 익명 사용자로 인증을 하지 않은 클라이언트를 뜻한다.

이번에는 JWT토큰을 발급받은 유저가 접근한다고 가정해보자.

해당 유저는 로그인에 성공하여 access토큰을 소유함으로써 자신이 누구인지 서버로부터 증명할 수 있는 상태이다.

그렇기 때문에 해당 유저는 자신을 증명하기 위해 request를 보낼때 토큰 또한 같이 보내야 서버에서 해당 토큰을 통해 유저를 파악할 수 있다.

그렇다면 request를 보낼때 토큰을 어떻게 전달해야 하는가?

simplejwt Getting started섹션을 보면 request header에 Authorization키로 'Bearer {access_token}'형식 값을 추가해서 전달하기만 하면 된다는걸 알 수 있다.

simplejwt-authorization-header.png

이번에는 request 헤더에 Authorization키로 위에서 설명한 형식대로 값을 추가하여 테스트를 해보면

postman-authorization-header-add.png

테스트에 사용된 토큰

antoliny0919.png

이번에는 AnonymousUser가 아닌 토큰을 발급받았던 유저 antoliny0919가 출력된걸 확인할 수 있다.

response-type.png

참고로 해당 값은 Django의 User모델 객체로써 이제 서버입장에서 request를 보낸 유저가 인증을 한 유저인지 아닌지 인증을 했다면 어떤 유저인지 정확히 파악할 수 있게 되었다.

이렇게 DRF에서 JWT토큰 발급은 Django의 장점이자 단점인 굉장한 깊이의 추상화 덕분인지 설치하고 복붙 딸깍 몇번하면 JWT토큰 발급/인증 로직을 구현할 수 있다.

이 과정까지만 알아도 로직을 완성하는데 무리가 없지만 필자같이 피곤한 사람들은 이러한 마법같은 현상에 매번 의문을 품고 판도라의 상자를 열려고 한다.

simplejwt 소스코드를 통해 로직 이해하기

필자는 urls.py에 아래와 같은 코드를 추가했다.

그리고 해당 '/api/token/'경로로 아이디와 비밀번호를 담은 HTTP request message를 보냈을때 refresh, access 토큰이 응답으로 주어지는걸 확인할 수 있었다.

그러면 <a href="https://github.com/jazzband/djangorestframework-simplejwt/blob/master/rest_framework_simplejwt/views.py">TokenObtainPairView</a>의 post메서드를 확인하면 위와같은 과정이 있지 않을까?

TokenObtainPairView는 settings.py에 있는 TOKEN_OBTAIN_SERIALIZER라는 값을 _serializer_class의 값으로 가지게 되고 TokenViewBase를 상속받은 형태이다.

필자는 settings.py에 JWT토큰관련 설정을 따로 커스텀 하지 않았기 때문에 <a href="https://github.com/jazzband/djangorestframework-simplejwt/blob/master/rest_framework_simplejwt/settings.py">simplejwt의 기본 설정</a>이 적용된다.

위 DEFAULT설정에서 'TOKEN_OBTAIN_SERIALIZER'라는 키를 확인할 수 있고

해당키의 값으로 "rest_framework_simplejwt.serializers.TokenObtainPairSerializer" 경로같이 생긴 문자열이 있는걸 알 수 있다.

즉 우리가 따로 settings.py에 simplejwt관련 설정을 하지 않았다면

<code class="inline-code">_serializer_class</code>의 값은 "rest_framework_simplejwt.serializers.TokenObatinPairSerializer"가 된다.

TokenObtainPairView는 이게 끝이기 때문에 실질적인 로직이 담겨있을 부모 클래스 <a href="https://github.com/jazzband/djangorestframework-simplejwt/blob/master/rest_framework_simplejwt/views.py#L12">TokenViewBase</a>를 확인해보자.

TokenViewBase에는 post메서드가 존재한다.

그 뜻은 '/api/token/' POST메서드로 request를 보내면 위 TokenViewBase의 post메서드가 동작하게 된다.

코드를 보면 <code class="inline-code">self.get_serializer(data=request.data)</code>로 serializer과정이 먼저 진행된다.

self.get_serializer는 TokenViewBase의 부모 클래스인 GenericAPIView의 메서드인데

아래와 같이 코드를 보면 <code class="inline-code">self.get_serializer_class()</code>를 호출하는걸 확인할 수 있다.

그렇다면 일단 먼저 확인해야할 코드는 TokenViewBase의 get_serializer_class메서드이다.

get_serializer_class메서드를 보면 가장먼저 <code class="inline-code">self.serializer_class</code>의 값을 우선하여 serializer_class로 지정하려 하지만 해당값은 따로 지정하지 않는 이상 <code class="inline-code">None</code>이기때문에 첫번째 조건문은 실패하게 된다.

그 다음은 import_string함수의 호출로 이전에 봤던 TokenObtainPairView에서 설정했던 <code class="inline-code">self._serializer_class</code>의 값을 인자로 전달한다.

참고로 DEFAULT에서 봤듯이 해당 값은 문자열 형태이다.

하지만 get_serializer_class에서 호출하는 <a href="https://github.com/django/django/blob/main/django/utils/module_loading.py#L19">import_string</a>함수는 <a href="https://docs.python.org/ko/3/library/importlib.html">importlib</a>내장모듈을 통해 위와같은 문자열을 파싱하여 해당경로의 파일을 동적으로 임포트하고 마지막 "."이후에 있는 TokenObtainPairSerializer클래스를 반환하게 된다. --&gt; cache_import의 return문에 해당.

DRF(Django REST framework) JWT토큰 발급하기(with simplejwt)

웹에는 다양한 인증방식이 존재한다.

그중에서 토큰을 통한 인증방식을 간단하게 아래 4단계로 분리해봤다.

authenticate_logic.png

1. 클라이언트가 아이디와 비밀번호를 HTTP Request Message Body에 담아 로그인을 요청

2. 서버에서 아이디와 비밀번호를 통해 회원가입한 유저라면 토큰을 Response

3. 인증이 필요한 로직에 Resource를 요청하기 위해 클라이언트가 HTTP Request + 헤더에 인증과 관련된 필드에 Token을 추가해서 전달

4. 서버에서 Request메시지의 헤더부분에서 인증과 관련된 헤더필드값(토큰)을 통해 유저를 파악후 Response 전달

놀랍게도 위와같은 과정은 DRF에서 굉장히 간단하게 구현할 수 있다.

일단 DRF와 같이 서버에서 가장 먼저 구현해야하는 부분은 2단계 토큰을 발급하는 단계이다.

DRF는 토큰을 발급하는 로직을 따로 제공한다.

먼저 settings.py에 'rest_framework.authtoken'을 추가하고 authtoken에는 Token모델이 따로 존재하기 때문에 migrate를 진행해야한다.

그다음 urlpatterns에 본인이 원하는 로그인과 관련된(토큰 발급)url경로와 해당 경로에 접근했을시 동작할 로직(View)으로 DRF에서 제공하는 ObtainAuthToken클래스를 사용하면된다.

로그인 API 경로

놀랍게도 토큰 발급을 위한 코드는 이게 끝이다.

response_token_insomnia.png

유저를 생성하여 API테스트를 진행해보면 Response로 token을 성공적으로 응답받은걸 확인할 수 있다.

클라이언트가 로그인에 성공해 token을 발급받았다.

그리고 클라이언트는 본인의 데이터를 얻고자 한다.

필자가 만든 UserView클래스는 굉장히 간단하다.

authentication_classes로 TokenAuthentication을 설정함으로써 해당 View는 인증이 필요한 로직을 의미하며 클라이언트는 본인을 인증하기 위해 Header에 인증과 관련된 필드값으로 토큰을 추가하여 HTTP Request메시지를 전송해야한다.

여기서 클라이언트가 먼저 알아야할건 인증과 관련된 필드가 무엇인가 이다.

document_authorization_field.png

인증과 관련된 필드는 <a href="https://www.django-rest-framework.org/api-guide/authentication/#tokenauthentication">DRF공식문서</a>에서 알 수 있듯이 Authorization이라는 키로 'Token {Token Value}'값을 HTTP Request헤더에 추가하여 전송하면 된다.

추가로 마지막 부분을 보면 성공적으로 인증될시 <code class="inline-code">request.user</code>는 Django의 User객체가 되고 <code class="inline-code">request.auth</code>는 전달한 Token객체가 된다.

실제로 테스트를 진행해보면

authorization_test_insomnia.png

헤더에 Authorization키와 값으로 'Token {Token Value}'를 추가하여 Request를 보냈더니 Token을 통해 판별한 유저로(<code class="inline-code">request.user</code>) 유저의 정보를 직렬화해 전달했기 때문에 응답으로 유저의 정보가 출력된걸 확인할 수 있다.

<code class="inline-code">UserSerializer(request.user)</code> --&gt; <code class="inline-code">Response(Serializer.data, ...)</code>

이러한 비밀을 파악하기 위해서는 View 동작에 대한 이해가 조금 필요하다.

&nbsp;DRF공식문서에서 <a href="https://www.django-rest-framework.org/api-guide/views/#dispatch-methods">API Guide Views페이지</a>를 보면 Dispatch methods와 관련된 글이 있다.

document_dispatch.png

간단하게 get, post, put, patch, delete 메서드는 dispatch메서드에 의해 직접 호출된다는 의미이다.

만약 클라이언트가 'api/user/' 경로와 함께 HTTP GET Method로 요청을 보내면 UserView의 get메서드가 호출될 것이고 get 메서드가 호출되기 전에 dispatch라는 메서드가 먼저 호출될 것이다.

그렇다면 dispatch메서드를 확인하기 위해 상속받은 APIView의 <a href="https://github.com/encode/django-rest-framework/blob/master/rest_framework/views.py#L485">dispatch메서드</a>를 확인해보자

만약 처음 dispatch메서드와 마주한다면 조금 복잡해보일 수 있으나 생각보다 굉장히 간단한 형태이다.

일단 이번 포스트는 인증과 관련된 부분만 설명할 것이기 때문에 dispatch메서드의 모든 코드를 이해할 필요는 없다.

우리가 Authentication이 어떻게 동작하는지 알기위해서는 dispatch메서드에서 아래 코드만 알면된다.

dispatch_know_2codeblock.png

상단에 있는 코드는 메서드명에서 유추할 수 있듯이 Request객체를 생성하는 동작이고 하단에 있는 코드블럭은 사실 이 부분은 인증과는 딱히 관련은 없지만 이해를 돕기위해 추가한 코드로 우리가 View에 작성한 메서드('get')가 실질적으로 호출되는 부분이다.

위 예제처럼 'api/user/'경로로 HTTP Request GET을 보냈다고 가정해보자

그리고 먼저 하단에 있는 코드부터 봐보면 먼저 조건검사가 진행되는데 request.method에는 우리가 요청한 HTTP Request의 메서드가 담겨있다. 즉 문자열 'GET'을 값으로 가질테고 lower메서드를 호출하여 소문자로 변환한다.

그 다음으로 변환된 'get'이 <code class="inline-code">self.http_method_names</code>에 존재해야하는데 http_method_names속성은 APIView의 부모클래스인 <a href="https://github.com/django/django/blob/main/django/views/generic/base.py#L42">View클래스의 클래스 변수</a>로 존재한다.

변수명 그대로 HTTP Method들을 배열에 가지고 있는 형태이고 Connect을 제외한 모든 HTTP Method들을 가지고 있다.

조건문 <code class="inline-code">if request.method.lower() in self.http_method_names</code>는 클라이언트가 보낸 HTTP Request가 Django View에서 허용하는 http_method로 요청했는지 확인하는 과정이다.

우린 GET으로 요청했기 때문에 조건문을 통과하게 되고 아래 코드를 실행한다.

<code class="inline-code">handler = getattr(self, request.method.lower(), self.http_method_not_allowed)</code>

getattr함수는 첫번째 인자로부터 두 번째 인자값의 속성을 가져오는 함수이다. 그리고 세 번째 인자는 없을때를 대비하는 default값이라고 보면 된다.

우리는 get메서드를 작성했기 때문에 self(UserView클래스 객체)에 get이라는 속성이 존재하고 getattr함수를 통해 get 메서드 객체를 가져와 handler변수에 할당하게 된다.

만약 우리가 get메서드를 구현하지도 않고 GET요청을 보냈다면 위 과정에서 handler는 <code class="inline-code">self.http_method_not_allowed</code>가 할당되게 되며 결국 해당 함수를 호출하게 되어 에러가 발생할 것이다.

실제로 get메서드 부분을 주석처리하고 다시 요청을 보내보면

terminal_method_not_allowed_err.png

method_not_allowed_response_insomnia.png

Method Not Allowed라는 에러를 확인할 수 있고 응답메시지도 아래 <a href="https://github.com/encode/django-rest-framework/blob/master/rest_framework/exceptions.py#L194">MethodNotAllowed클래스</a>에서 생성된 메시지라는걸 알 수 있다.

하지만 우린 정상적으로 get메서드를 구현했기 때문에 구현한 get메서드 객체가 위에서도 설명했듯이 handler변수에 할당되고 마지막으로 handler함수를 호출하게 되어 결국 우리가 작성한 메서드들이 이 과정에서 호출된다.

<code class="inline-code">response = handler(request, *args, **kwargs)</code>

call_get_time.png

사실 위 부분은 앞에서도 말했듯이 인증과 관련된 코드가 등장하는 부분은 아니지만 따로 설명한 이유는 필자가 초반에 DRF 공식문서 API Guides View페이지 Dispatch Method와 관련된 글을 첨부하면서 

해당 문서에 "get, post, put, patch, delete 메서드는 dispatch메서드에 의해 직접 호출된다"라고 소개한 부분이 있는데

이 부분을 실제로 보여주기 위함이였다.

이제 진짜 인증과 관련된 동작들을 알아볼 차례다.

DRF(Django REST framework)는 어떻게 인증을 구현했는가?

현재 필자의 웹사이트에는 관리자를 제외한 두 명의 유저가 존재한다.

user-state-excalidraw-2.png

그리고 안톨리니와 버터링은 각각 자신이 작성한 포스트도 하나 가지고있다.

user-post-excal.png

현재 버터링은 자신이 만든 포스트가 맘에 들지 않아서 삭제하려고 한다.

포스트를 삭제하기 위해서는 서버에 HTTP Request DELETE 메서드로 '/api/posts/{삭제할 포스트 id}/'경로로 요청하기만 하면 된다.

버터링의 포스트 id값은 위 그림에서 볼 수 있듯이 '4'이므로 '/api/posts/4/' 경로로 요청하면 된다는걸 알 수 있지만

버터링이 실수로 5를 입력하여 자신이 소유한 포스트가 아닌 안톨리니의 포스트를 삭제하려고 하면 어떻게 될까?

delete-antoliny-post.png

버터링이 '/api/posts/5/'경로로 요청을 보냈고 Response Status Code가 204인걸 보면 자신이 소유하지않은 포스트는 삭제되면 안되지만 전체 포스트를 다시 확인했을때 안톨리니의 포스트가 존재하지 않는걸로 보아 실수로 잘못보낸 삭제 요청이 받아들여져 클라이언트의 의도와는 달리 동작해버린걸 확인할 수 있다.

after-delete-antoliny-post-all.png

현재 필자의 웹사이트는 위 사례에서 봤듯이 관리자가 아닌 일반 유저가 자신이 소유하지 않은 포스트를 삭제할 수 있는 치명적인 버그가 존재한다.

만약 수 많은 유저들이 존재하는 웹사이트에서 버터링은 고의가 아니였지만 해당 버그를 악용하는 유저가 존재한다고 상상하면 아마 그 웹 사이트는 데이터 백업을 하지 않았다면 문을 닫아야&nbsp; 될지도 모른다.

결론은 위와 같은 버그는 권한이 설정되어 있지 않아서 발생한 문제이다.

필자의 웹사이트 소스코드를 수정하여 권한과 관련된 문제가 발생하지 않도록 해보겠다.

DRF는 권한을 언제 확인할까?

일단 필자의 소스코드를 수정하기 전에 DRF가 권한을 확인하는 시점에 대해서 알아보겠다.

DRF에서 사용자가 정의한 View로직이 호출될때 <a href="https://github.com/encode/django-rest-framework/blob/master/rest_framework/views.py#L485">APIView의 dispatch메서드</a>에 의하여 호출되는데

"# --------"내부 코드가 사용자가 정의한 View로직이 호출되는 구간이다.

만약 필자가 아래와 같이 TestView를 작성했다고 가정했을때

client가 'test/'경로로 GET요청을 보낸다면 결론적으로 위 get메서드 객체가 Dispatch메서드 "#----"내부 마지막에 있는 handler변수에 할당되어 호출되는 식이다.

즉 <code class="inline-code">handler(request, *args, **kwargs)</code>가 사실상 TestView의 <code class="inline-code">get(request, *args, **kwargs)</code>이라고 보면된다.

필자의 웹사이트에서 발생한 버그는 권한과 관련된 문제였다.

그렇다면 일단 client의 권한을 파악하기 위해서는 request를 요청한 client가 누구인지부터 알아야 해당 유저가 어떤 권한이 있는지 파악할 수 있다.

항상 권한을 확인하기 전에 해결되어야 하는 부분은 인증부분이다.

위에서도 설명했듯이 요청을 보낸 클라이언트가 누구인지 알아야 해당 클라이언트의 권한을 확인할 수 있기 때문이다.

필자의 웹사이트는 인증 클래스로 DRF에서 제공하는 Token인증을 사용했다.

그렇기때문에 클라이언트가 Request를 요청할때 Request Header에 Authorization 필드를 추가하여 요청하면 서버에서

Request를 요청한 클라이언트가 누구인지 정확히 파악할 수 있다.

테스트를 위해 authentication_classes로 TokenAuthentication을 가졌고 응답으로 <code class="inline-code">request._request.user</code> --&gt; request한 클라이언트의 username을 반환하는 로직을 작성했다.

버터링이 위와같은 View에 요청할때 HTTP Header에 본인의 토큰값을 Authorization키값에 담아서 전달할 것이고

응답으로 본인의 username인 "butterring"이 반환될것이라고 예상할 수 있다.

test-auth-terminal-butterring.png

실제로 curl을 통해 버터링의 토큰값을 담아 요청해보면 <code class="inline-code">request._request.user</code>의 값으로 버터링의 username인 "butterring"이 반환되는걸 확인할 수 있다.

이렇게 인증을 구현함으로써 이제 request를 보낸 클라이언트가 누구인지 정확히 파악할 수 있는 단계가 되었다.

즉 이번 포스트의 주요내용인 권한과 관련된 코드를 작성할 준비가 다되었다는 의미이다.

인증을 구현하는 방법?

DRF에서 Permission이 수행되는 과정

버터링과 안톨리니는 같은 등급(일반)의 유저이지만

만약 필자의 웹사이트에서 포스트를 삭제하는 기능은 어드민 유저에게만 허락된다고 가정해보자

권한이 없는 안톨리니가 포스트를 삭제하는 request를 보낸 상황이다.

버터링은 권한이 없기 때문에 위 delete메서드에 도달하기 전에 403 상태코드를 담은 response를 반환해야 할 것이다.

일단 필자가 이전에 사용자가 작성한 View는 APIView의 dispatch메서드에서 '#----'블럭 내부에서 호출된다고 했었다.

그렇기 때문에 해당 블럭에 도달하기전에 권한이 존재하지 않다는 응답을 반환해야 할것이다.

'#-----'블럭 바로 위에 <code class="inline-code">self.initial(request, *args, **kwargs)</code>라는 코드가 있고 <a href="https://github.com/encode/django-rest-framework/blob/master/rest_framework/views.py#L399">initial메서드</a>를 호출하는 부분으로 initial메서드를 확인해보면

마지막부분에 <code class="inline-code">self.perform_authentication(request)</code>와 <code class="inline-code">self.check_permissions</code>라는 코드가 있다.

참고로 <code class="inline-code">self.perform_authentication</code>은 메서드명 그대로 인증을 이행하는 메서드로 실행되면 인증과 관련된 과정이 진행되며 해당 시점부터 request를 전송한 클라이언트가 누구인지 정확히 알고 있는 상태이다.

그래서 <code class="inline-code">self.perform_authentication</code>이 진행되면 버터링이라는 유저가 요청을 보냈다는걸 서버입장에서 알고 다음코드인 <code class="inline-code">self.check_permissions</code>를 통해 요청을 보낸 유저가 요청을 이행할 수 있는 권한이 존재하는 클라이언트인지 검증하는 과정을 거친다.

check_permissions메서드는 이름 그대로 권한을 체크하는 부분이다.

코드를 보면 가장 먼저 <a href="https://github.com/encode/django-rest-framework/blob/master/rest_framework/views.py#L274">self.get_permissions()메서드</a>를 호출하는데

self.get_permissions메서드는 메서드명 그대로 권한 클래스들을 가져오는 메서드이다.

get_permissions메서드는 <code class="inline-code">self.permission_classes</code>값을 사용하는데 APIView에서 permission_classes의 값은 <code class="inline-code">api_settings.DEFAULT_PERMISSION_CLASSES</code>이다.

참고로 api_settings는 사용자의 프로젝트 settings.py에 따로 정의되어 있다면 해당 값을 가져오고 만약 정의되어 있지 않다면 rest_framework가 제공하는 settings.py 기본값을 따르게 된다.

간단하게 필자의 settings.py에 아래와 같은 코드가 추가되었다면

APIView의 permission_classes는 IsAuthenticated클래스가 되고 만약 사용자가 정의한 로직에 permission_classes를 오버라이딩 하지 않았다고 가정하면 사용자가 정의한 모든 로직에 IsAuthenticated클래스가 permission_classes로 사용된다.

그렇기 때문에 모든 로직에 기본적으로 적용하고 싶은 권한이 있다 라는 상황이라면 사용자의 settings.py에 위와같은 형태로 자신이 원하는 권한 클래스를 지정하면 된다.

사용자의 settings.py에도 'DEFAULT_PERMISSION_CLASSES'를 재정의 하지 않고 호출된 로직에서도 permission_classes를 오버라이딩 하지 않은 상황에서는 앞서 설명했듯이 rest_framework가 제공하는 settings.py 기본값을 따르게 된다.

settings.py의 permission_classes기본값으로 <a href="https://github.com/encode/django-rest-framework/blob/master/rest_framework/permissions.py#L133">AllowAny클래스</a>를 사용하는데 클래스명 그대로 어떠한 유저든 허용한다는 권한 클래스이다.(권한검증을 하지 않는다와 같다.)

permission-classes-seniority.png

필자는 포스트를 삭제하는 기능을 어드민에게만 허용하려고 한다.

필자는 포스트와 관련된 View에 permission_classes로 어드민만 권한을 허용하는 <a href="https://github.com/encode/django-rest-framework/blob/master/rest_framework/permissions.py#L154">IsAdminUser클래스</a>를 추가하는식으로 문제를 해결하였다.

참고로 이전에봤던 권한 클래스 IsAuthenticated, AllowAny, IsAdminUser 전부 다 DRF에서 제공하는 권한 클래스이다.

필자의 PostView가 사용하는 IsAdminUser클래스를 예시로 has_permission메서드의 반환값은 <code class="inline-code">request.user</code> --&gt; 요청을 보낸 유저가 is_staff필드값(<code class="inline-code">request.user.is_staff</code>)이 True이면 True를 반환하게 된다.(권한 허용)

이제 어드민 유저가 아닌 버터링이 포스트 삭제를 시도하면