Ich mag Django und berühre es privat, aber es gibt nur wenige Artikel rund um das Django REST Framework (DRF) in Qiita ... (Zum Zeitpunkt des Schreibens dieses Artikels) 159 Fälle) Ich denke, DRF ist eine der attraktivsten Optionen in der gegenwärtigen Situation, in der es ein sehr leistungsfähiges Framework ist und es üblich wird, das Front-End und die Serverseite getrennt zu entwickeln. Auf der anderen Seite gibt es nur wenige Artikel und Fachbücher auf Japanisch, und wenn es wichtig wird, englische Dokumente zu lesen, wird dies meiner Meinung nach den Eindruck erwecken, dass es für Menschen, die kein Englisch sprechen können, schwierig ist. Insbesondere habe ich es geschrieben, weil ich denke, dass es in der Regel auf Englisch geschrieben ist, das selbst Anfänger selbst auf Japanisch nicht verstehen können.
Dies ist ein Bereich, der sich auf die Zugriffskontrolle bezieht.
Authentication or identification by itself is not usually sufficient to gain access to information or code. For that, the entity requesting access must have authorization. Apple Developer Documentation
Wie in der Entwicklerdokumentation von Apple angegeben, wird allgemein angenommen, dass Authentifizierung und Identifizierung allein nicht ausreichen, um auf Informationen oder Code zuzugreifen, und dass die Entität, die den Zugriff anfordert, über Berechtigungen verfügen muss.
Diese DRF-Berechtigung wird zu Beginn der Ansicht ausgeführt, und bei der Berechtigungsprüfung werden normalerweise die Anmeldeinformationen der Eigenschaften "request.user" und "request.auth" verwendet, um zu bestimmen, ob die Anforderung zugelassen werden soll.
DRF-Berechtigungen werden immer als Liste von Berechtigungsklassen definiert.
Jede Berechtigung in der Liste wird überprüft, bevor der Hauptteil der Ansicht ausgeführt wird. Wenn dies fehlschlägt, wird eine Ausnahme von "Ausnahmen.PermissionDenied" ausgelöst und der Hauptteil wird nicht mehr ausgeführt.
DRF-Berechtigungen unterstützen auch Berechtigungen auf Objektebene, mit denen bestimmt wird, ob ein Benutzer an einem bestimmten Objekt (normalerweise einem Modell) arbeiten darf.
Wenn Sie Ihre eigene Ansicht erstellen und Berechtigungen auf Objektebene anwenden oder die Methode in der generischen Ansicht "get_object" überschreiben möchten, verwenden Sie die Ansichtsmethode, wenn Sie die Ansicht ".check_object_permissions (request, obj)" erhalten. Muss angerufen werden.
Dies wird fortgesetzt, wenn die Ansicht über die entsprechenden Berechtigungen verfügt, und gibt eine Ausnahme "Berechtigung verweigert" oder "Nicht authentifiziert" zurück, wenn Sie nicht über die Berechtigungen verfügen.
Die Standardeinstellungen für Autorisierungsrichtlinien werden mit "DEFAULT_PERMISSION_CLASSES" festgelegt.
settings.py
REST_FRAMEWORK = {
'DEFAULT_PERMISSION_CLASSES': (
'rest_framework.permissions.IsAuthenticated',
)
}
Wenn nicht angegeben, verwenden Sie "AlloWAny".
settings.py
REST_FRAMEWORK = {
'DEFAULT_PERMISSION_CLASSES': (
'rest_framework.permissions.AllowAny',
)
}
Sie können den Authentifizierungsbereich auch für jede Ansicht und jedes Ansichtsset mithilfe der klassenbasierten Ansicht von APIView festlegen.
views.py
from rest_framework.permissions import IsAuthenticated
from rest_framework.response import Response
from rest_framework.views import APIView
class ExampleView(APIView):
permission_classes = (IsAuthenticated,)
def get(self, request, format=None):
content = {
'status': 'request was permitted'
}
return Response(content)
Eine andere Möglichkeit zum Schreiben besteht darin, eine funktionsbasierte Ansicht mit dem Dekorator @api_view zu schreiben.
views.py
@api_view('GET')
@permission_classes((IsAuthenticated, ))
def example_view(request, format=None):
content = {
'status': 'request was permitted'
}
return Response(content)
AllowAny
Die AllowAny-Klasse ermöglicht uneingeschränkten Zugriff, unabhängig davon, ob die Anforderung authentifiziert ist oder nicht. Die Verwendung einer leeren Liste oder eines leeren Taples zum Festlegen von Berechtigungen führt zu ähnlichen Ergebnissen. Dies ist nicht unbedingt erforderlich, aber für explizite Absichten hilfreich.
IsAuthenticated Die IsAuthenticated-Klasse verweigert jeden nicht authentifizierten Benutzer und gewährt andere Berechtigungen. Es wird verwendet, um es nur Benutzern zugänglich zu machen, die in der API registriert sind.
IsAdminUser Die IsAdminUser-Klasse verweigert alle Benutzer, außer wenn "user.is_staff" "True" ist.
IsAuthenticatedOrReadOnly Mit der IsAuthenticatedOrReadOnly-Klasse kann ein authentifizierter Benutzer jede Anforderung stellen. Anfragen von nicht autorisierten Benutzern sind auf Fälle beschränkt, in denen die Anforderungsmethode eine sichere Methode wie "GET", "HEAD" oder "OPTIONS" ist.
Dies ist geeignet, wenn Sie anonymen Benutzern mit API Leseberechtigungen und authentifizierten Benutzern Schreibberechtigungen erteilen möchten.
DjangoModelPermissions
DjangoModelPermissions ist an die Berechtigungen des Standard-Django-Modells django.contrib.auth gebunden.
Es sollte nur auf Ansichten angewendet werden, für die die Eigenschaft ".queryset" festgelegt ist, und wird genehmigt, wenn der Benutzer authentifiziert und die entsprechenden Modellberechtigungen zugewiesen wurden.
Als Beispiel,
Für die POST-Anforderung muss der Benutzer über Berechtigungen für das Modell "Hinzufügen" verfügen.
Für "PUT" - und "PATCH" -Anforderungen sind Berechtigungen für das "Änderungs" -Modell erforderlich
Die Anforderung "Löschen" erfordert Berechtigungen für das Modell "Löschen"
Es ist geworden.
Sie können auch das Standardverhalten überschreiben, um benutzerdefinierte Modellberechtigungen zu unterstützen. Die Ansicht kann beispielsweise GET-Anforderungsberechtigungen enthalten.
Wenn Sie die überschriebene Methode "get_query ()" verwenden, enthält sie möglicherweise nicht das Attribut "queryset". In diesem Fall wird empfohlen, die Ansicht wie unten gezeigt mit dem erforderlichen "Querset" zu markieren.
queryset = User.objects.none() #Erforderlich für DjangoModelPermissions
DjangoModelPermissionsOrAnonReadOnly Ähnlich wie bei den oben genannten DjangoModelPermissions, ermöglicht dies jedoch nicht authentifizierten Benutzern den schreibgeschützten Zugriff auf die API.
DjangoObjectPermissions
Es funktioniert mit der Standard-Objektberechtigungsklasse von Django, die Objektberechtigungen für das Modell zulässt. Wenn Sie es verwenden möchten, müssen Sie ein Berechtigungs-Backend hinzufügen, das Berechtigungen auf Objektebene wie "Django-Guardian" unterstützt.
Beachten Sie, dass für "DjangoObjectPermissions" das Paket "django-guardian" nicht erforderlich ist und auch andere Backends auf Objektebene unterstützt werden sollten.
Ähnlich wie bei "DjangoModelPermissions" sollte diese Berechtigung nur auf Ansichten mit ".queryset" angewendet werden und wird nur erteilt, wenn der Benutzer authentifiziert und die Berechtigungen des Objekts und die zugehörigen Modellberechtigungen zugewiesen wurden. .. Darüber hinaus können Sie benutzerdefinierte Modellberechtigungen verwenden, indem Sie "DjangoModelPermissions" überschreiben.
TokenHasReadWriteScope Es soll entweder mit der Klasse "OAuthAuthentication" oder "OAuth2Authentication" verwendet werden. Nur sichere Methoden wie "GET", "OPTIONS" oder "HEAD" sind zulässig, wenn dem authentifizierten Token eine Leseberechtigung zugewiesen wurde.
Benutzerdefinierte Berechtigungen implementieren Überschreiben Sie eine oder beide der folgenden Methoden in "BasePermission":
.has_permission(self,request,view).has_object_permission(self,request,view,obj)Die Methode gibt "True" zurück, wenn Sie der Anforderung Zugriff zuweisen möchten, andernfalls "False".
Wenn Sie testen müssen, ob eine Anforderung eine Lese- oder Schreiboperation ist, können Sie "GET", "OPTIONS" und "HEAD" für Konstanten verwenden, die Tupel sind, die "SAFE_METHODS" enthalten, wie unten gezeigt. Sie müssen die Anforderungsmethode wie überprüfen.
if request.method in permissions.SAFE_METHODS:
# Check permissions for read-only request
else:
# Check permissions for write request