Django For API 주석 - 섹션 3

Django for API는 Django와 Django REST 프레임워크를 사용하여 현대 API를 구축하는 방법에 대한 프로젝트 기반 안내서입니다.API를 구축하지 않은 초보자, Django의 기초 지식과 모범 사례를 빠르게 이해하고자 하는 전문 프로그래머에게 적용됩니다.
이것들은 이 책의 중요한 주석과 코드 세션으로 기존의 Django 사이트를 웹 API로 확장하는 데 도움이 되며, 0에서 시작하여 위탁 관리와 API 문서의 모든 내용을 포함한다.우리는 세 번째 부분에서 서로 다른 유형의 사용자 인증 방법을 토론할 것이다.
시작합시다!

Read and

사용자 인증

승인: API 권한

인증: 사용자가 새 계정을 등록하고 로그인하고 로그아웃할 수 있는 과정

기본 인증:
가장 일반적인 HTTP 인증을 기본 인증이라고 합니다.클라이언트가 HTTP 요청을 하면 액세스 권한을 부여하기 전에 승인된 인증 자격 증명을 보내야 합니다.
전체 요청/응답 흐름은 다음과 같습니다.

클라이언트에서 HTTP 요청

서버 응답 HTTP 응답401 (Unauthorized) 상태 코드와 WWW-Authenticate HTTP 헤드, 권한 수여 방법에 대한 상세한 정보

포함

클라이언트가 Authorization HTTP 헤드

를 통해 자격 증명을 반송합니다.

서버 검사 증명서를 사용하고 200 OK 또는 403 Forbidden 상태 코드로 응답합니다.
승인되면 클라이언트는 라이센스 HTTP 헤드 자격 증명을 사용하여 모든 향후 요청을 보냅니다.

Note: The authorization credentials sent are the unencrypted base64 encoded version of <username>:<password>.

속임수:

각 요청에 대해 서버에서 사용자 이름과 비밀번호를 찾아 검증해야 하는데 이것은 비효율적이다.

사용자 증빙서류는 명문 형식으로 전달되고 암호화되지 않아 쉽게 포획하고 다시 사용할 수 있다.

Note: Basic authentication should only be used via HTTPS, the secure version of HTTP.

세션 인증:
높은 수준에서 클라이언트는 자격 증명(사용자 이름/암호)을 사용하여 인증한 다음 서버에서 cookie로 저장된 세션 ID를 받습니다.그런 다음 세션 ID는 향후 각 HTTP 요청의 헤더로 전달됩니다.서버는 세션 ID를 전달할 때 해당 사용자에 대해 사용 가능한 모든 정보(자격 증명 포함)가 들어 있는 세션 객체를 검색하는 데 사용합니다.이 방법은 서버(세션 대상)와 클라이언트(세션 ID)에서 기록을 보존하고 유지해야 하기 때문에 상태가 있습니다.
이제 기본 프로세스를 살펴보겠습니다.

사용자가 로그인 자격 증명(일반적으로 사용자 이름/암호)을 입력합니다

.

서버에서 자격 증명이 올바른지 확인하고 세션 객체를 생성하여 데이터베이스

에 저장

서버는 클라이언트 기기에 세션 ID를 보내고 세션 대상 자체가 아니라 후자는 쿠키로 브라우저에 저장한다

이후의 모든 요청에 세션 ID가 HTTP 헤더에 포함되며 데이터베이스 검증을 거치면 요청이 계속됩니다

사용자가 애플리케이션에서 로그아웃하면 클라이언트와 서버가 세션 ID

를 제거합니다.

사용자가 나중에 다시 로그인하면 새로운 세션 ID를 생성하여 쿠키로 클라이언트에 저장

Note: The default setting in Django REST Framework is actually a combination of Basic Authentication and Session Authentication. Django’s traditional session-based authentication system is used and the session ID is passed in the HTTP header on each request via Basic Authentication.

찬성 의견:

사용자 증명서는 기본 인증처럼 요청/응답 주기마다 한 번만 발송하지 않습니다.

서버가 사용자의 자격 증명을 매번 검증할 필요가 없기 때문에 세션 ID를 세션 대상과 일치시키기만 하면 된다. 이것은 빠른 검색이다.

속임수:

세션 ID는 로그인을 실행하는 브라우저에서만 유효합니다.그것은 여러 개의 영역을 뛰어넘어 일할 수 없다.API가 웹 사이트나 모바일 애플리케이션과 같은 여러 개의 프런트엔드를 지원해야 할 때, 이것은 명백한 문제이다.

세션 객체는 최신 상태로 유지되어야 하며 여러 서버가 있는 대규모 사이트에서는 어려울 수 있습니다.

모든 요청은 쿠키를 발송하는데 신분 검증이 필요 없는 요청도 마찬가지다. 이것은 저효과이다.

Note: It is generally not advised to use a session-based authentication scheme for any API that will have multiple front-ends.

토큰 인증
영패 기반의 신분 검증은 무상태이다. 클라이언트가 서버에 초기 사용자 자격 증명을 보내면 유일한 영패를 생성하고 클라이언트가 이를 쿠키나 로컬 저장소로 저장한다.그리고 이 영패를 모든 HTTP 요청의 헤더에 전달하고 서버는 이를 사용하여 사용자가 인증을 받았는지 확인합니다.

The server itself does not keep a record of the user, just whether a token is valid or not.

Cookies vs localStorage

- Cookies are used for reading server-side information. 
They are smaller (4KB) in size and automatically sent with each HTTP request. 

- LocalStorage is designed for client-side information. 
It is much larger (5120KB) and its contents are not sent by default with each HTTP request.

Tokens stored in both cookies and localStorage are vulnerable to XSS attacks. 
The current best practice is to store tokens in a cookie with the httpOnly and Secure cookie flags.

참고 HTTP 헤드 WWW Authenticate는 응답 라이센스 헤드 요청에 사용할 토큰의 사용을 지정합니다.
찬성 의견:

토큰이 클라이언트에 저장되어 있기 때문에 서버를 확장하여 최신 세션 대상을 유지하는 것은 더 이상 문제가 되지 않는다.

영패는 여러 개의 전방에서 공유할 수 있다. 같은 영패는 사이트의 한 사용자를 대표할 수도 있고 모바일 응용 프로그램의 한 사용자를 대표할 수도 있다.

속임수:

영패는 세션 id/세션 대상이 설정되었을 때의 id뿐만 아니라 모든 사용자 정보를 포함한다.요청마다 영패를 보내기 때문에 크기를 관리하는 것이 성능 문제가 될 수 있습니다.

Django REST 프레임워크의 내장형 토큰 인증:

토큰이 만료되는 것은 지원되지 않습니다

사용자당 하나의 토큰만 생성

JSON 웹 토큰(JWT):
JSON 웹 영패(JWT)는 새로운, 강화된 영패 버전으로 몇 개의 제3자 패키지를 통해 Django REST 프레임워크에 추가할 수 있다.

JWT는 유일한 클라이언트 영패와 영패가 만료되는 것을 포함하는 몇 가지 장점이 있다.

이들은 서버에서 생성할 수도 있고 제3자 서비스(예를 들어 Auth0)로 생성할 수도 있다.

와 JWT는 암호화되어 안전하지 않은 HTTP 연결에서 더욱 안전하게 발송할 수 있다.

DRF의 기본 인증

기본 사용 권한 클래스: AllowAny

기본 인증 클래스: 세션 인증과 기본 인증입니다.

REST_FRAMEWORK = {
    'DEFAULT_PERMISSION_CLASSES': [
        'rest_framework.permissions.IsAuthenticated',
    ],
    'DEFAULT_AUTHENTICATION_CLASSES': [  # new
        'rest_framework.authentication.SessionAuthentication',
        'rest_framework.authentication.BasicAuthentication'
    ],
}

왜 이 두 가지 방법을 동시에 사용해야 합니까?

세션은 조회 가능한 API와 로그인 및 로그아웃 기능에 동력을 제공합니다.

기본 인증은 API 자체의 HTTP 헤더에서 세션 ID를 전달하는 데 사용됩니다.

토큰 인증
첫 번째 단계는 DEFAULT_AUTHENTICATION_CLASSES 설정을 사용 TokenAuthentication로 업데이트하는 것입니다. 다음과 같습니다.

REST_FRAMEWORK = {
    'DEFAULT_PERMISSION_CLASSES': [
        'rest_framework.permissions.IsAuthenticated',
    ],
    'DEFAULT_AUTHENTICATION_CLASSES': [
        'rest_framework.authentication.SessionAuthentication',
        'rest_framework.authentication.TokenAuthentication',  # new
    ],
}

Session Authentication을 보류합니다. 방문할 수 있는 API가 여전히 필요하지만, 현재 HTTP 헤더에서 인증서를 전달하기 위해 영패를 사용합니다.

서버에 영패를 생성하는 authtoken 프로그램을 추가해야 합니다.Django REST 프레임에 포함되지만 INSTALLED_- APPS 설정에 추가해야 합니다.

'rest_framework.authtoken',

Django Rest Auth
사용자가 로그인, 로그오프 및 암호를 재설정할 수 있도록 API 끝점을 생성합니다.

설치django-rest-auth 구성 요소

pip install django-rest-auth

설정의 INSTALLED_APPS 구성에 새 애플리케이션을 추가합니다.py

'rest_auth',

URL에 라우트를 설정합니다.py

path('api/v1/rest-auth/', include('rest_auth.urls')), 

사용자 등록
기존 Django는 사용자 등록을 위한 내장 뷰나 URL을 제공하지 않으며, Django REST 프레임워크도 제공하지 않습니다.
한 가지 유행하는 방법은 제3자 패키지인 django allauth를 사용하는 것이다. 이 패키지는 사용자 등록과 django auth 시스템의 일부 부가 기능, 예를 들어 페이스북, 구글, 트위터 등을 통해 사회 인증을 하는 것이다.

설치django-allauth 구성 요소

pip install django-allauth

업데이트 INSTALLED_APPS 설정

'django.contrib.sites',
'allauth',
'allauth.account',
'allauth.socialaccount',
'rest_auth.registration',

확보EMAIL_BACKEND와SITE_ID도 포함된다.

Note: Technically it does not matter where in the settings.py file they are placed, but it’s common to add additional configs like that at the bottom.

EMAIL_BACKEND = 'django.core.mail.backends.console.EmailBackend' # new
SITE_ID = 1 # new

Note:

• The email back-end config is needed since by default an email will be sent when a new user is registered, asking them to confirm their account. Rather than also set up an email server, we will output the emails to the console with the console.EmailBackend
  setting.

• SITE_ID is part of the built-in Django “sites” framework which is a way to host multiple websites from the same Django project. We obviously only have one site we are working on here but django-allauth uses the sites framework, so we must specify
  a default setting.

등록을 위한 URL 라우팅 추가

path('api/v1/rest-auth/registration/', include('rest_auth.registration.urls')),

Read Part IV

자세한 내용은 GitHub를 참조하십시오.
만약 네가 이 필기들을 읽는 것을 좋아한다면, 반드시 평론에서 나에게 너의 관점을 알려줘야 한다.연락하려면 다음 링크를 클릭하십시오.
| GitHub | | StackOverflow