J'aime Django et le touche en privé, mais il y a peu d'articles autour de Django REST Framework (DRF) dans Qiita ... (Au stade de la rédaction de cet article) 159 cas) Je pense que DRF est l'une des options les plus attrayantes dans la situation actuelle où il s'agit d'un framework très puissant et il devient courant de développer séparément le front-end et le serveur. Par contre, il y a peu d'articles et de livres techniques en japonais, et s'il devient indispensable de lire des documents anglais, je pense que cela donnera l'impression que c'est difficile pour les gens qui ne parlent pas anglais. Surtout, je l'ai écrit parce que je pense qu'il a tendance à être écrit en anglais que même les débutants ne peuvent pas comprendre même en japonais.
Il s'agit d'un domaine lié au contrôle d'accès.
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
Comme indiqué dans la documentation destinée aux développeurs d'Apple, il est généralement admis que l'authentification et l'identification seules ne suffisent pas pour accéder aux informations ou au code, et que l'entité qui demande l'accès doit disposer d'autorisations.
Cette autorisation DRF est exécutée au début de la vue et la vérification des autorisations utilise généralement les informations d'identification des propriétés «request.user» et «request.auth» pour déterminer s'il faut autoriser la requête.
Les autorisations DRF sont toujours définies comme une liste de classes d'autorisation.
Chaque autorisation de la liste est vérifiée avant d'exécuter le corps de la vue, et si elle échoue, une exception de ʻexceptions.PermissionDenied` est levée et le corps cesse de fonctionner.
Les autorisations DRF prennent également en charge les autorisations au niveau de l'objet, qui sont utilisées pour déterminer si un utilisateur est autorisé à travailler sur un objet particulier (généralement un modèle).
Si vous créez votre propre vue et lui appliquez des autorisations au niveau objet, ou si vous voulez remplacer la méthode dans la vue générique get_object, utilisez la méthode view lorsque vous obtenez la vue .check_object_permissions (request, obj). Doit être appelé.
Cela continuera si la vue dispose des autorisations appropriées et renverra une exception PermissionDenied ou NotAuthenticated si vous ne disposez pas des autorisations.
Les paramètres de stratégie d'autorisation par défaut sont définis à l'aide de «DEFAULT_PERMISSION_CLASSES».
settings.py
REST_FRAMEWORK = {
'DEFAULT_PERMISSION_CLASSES': (
'rest_framework.permissions.IsAuthenticated',
)
}
Si non spécifié, utilisez ʻAlloWAny`.
settings.py
REST_FRAMEWORK = {
'DEFAULT_PERMISSION_CLASSES': (
'rest_framework.permissions.AllowAny',
)
}
Vous pouvez également définir la portée de l'authentification pour chaque vue et chaque ensemble de vues à l'aide de la vue basée sur les classes APIView.
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)
Une autre façon de l'écrire est d'écrire une vue basée sur des fonctions à l'aide du décorateur @api_view.
views.py
@api_view('GET')
@permission_classes((IsAuthenticated, ))
def example_view(request, format=None):
content = {
'status': 'request was permitted'
}
return Response(content)
AllowAny
La classe AllowAny permet un accès illimité, que la demande soit authentifiée ou non. L'utilisation d'une liste vide ou d'une touche pour définir les autorisations donnera des résultats similaires, ce n'est donc pas strictement nécessaire, mais c'est utile pour une intention explicite.
IsAuthenticated La classe IsAuthenticated refuse tout utilisateur non authentifié et accorde d'autres privilèges. Il est utilisé pour le rendre accessible uniquement aux utilisateurs enregistrés dans l'API.
IsAdminUser
La classe IsAdminUser refuse tous les utilisateurs sauf lorsque ʻuser.is_staff vaut True`.
IsAuthenticatedOrReadOnly La classe IsAuthenticatedOrReadOnly permet à un utilisateur authentifié de faire n'importe quelle demande. Les demandes d'utilisateurs non autorisés sont limitées aux cas où la méthode de demande est une méthode sécurisée telle que «GET», «HEAD» ou «OPTIONS».
Il convient lorsque vous souhaitez accorder une autorisation de lecture à des utilisateurs anonymes avec API et une autorisation d'écriture à des utilisateurs authentifiés.
DjangoModelPermissions
DjangoModelPermissions est lié aux permissions du modèle Django standard django.contrib.auth.
Il ne doit être appliqué qu'aux vues qui ont la propriété .queryset définie et sera approuvé si l'utilisateur est authentifié et attribué les autorisations de modèle appropriées.
Par exemple,
La requête POST nécessite l'autorisation de l'utilisateur pour le modèle ʻadd`
Les requêtesPUT et PATCH nécessitent des autorisations sur le modèle change
La requêteDELETE nécessite des autorisations sur le modèle delete
Il est devenu.
Vous pouvez également remplacer le comportement par défaut pour prendre en charge les autorisations de modèle personnalisé, par exemple, la vue peut inclure des autorisations de requête GET.
Si vous utilisez la méthode get_query () remplacée, elle peut ne pas inclure l'attribut queryset. Dans ce cas, il est recommandé de marquer la vue avec le querset requis comme indiqué ci-dessous.
queryset = User.objects.none() #Requis pour DjangoModelPermissions
DjangoModelPermissionsOrAnonReadOnly
Similaire à DjangoModelPermissions ci-dessus, mais cela permet aux utilisateurs non authentifiés d'avoir un accès en lecture seule à l'API.
DjangoObjectPermissions
Il fonctionne avec la classe d'autorisation d'objet standard de Django, qui autorise des autorisations par objet sur le modèle.
Si vous souhaitez l'utiliser, vous devez ajouter un backend d'autorisation qui prend en charge les autorisations au niveau de l'objet telles que django-guardian.
Notez que DjangoObjectPermissions ne nécessite pas le package django-guardian et devrait également prendre en charge d'autres backends au niveau objet.
Semblable à DjangoModelPermissions, cette autorisation ne doit être appliquée qu'aux vues avec .queryset et ne sera accordée que si l'utilisateur a été authentifié et a reçu les autorisations de l'objet et du modèle associé. ..
En outre, vous pouvez utiliser des autorisations de modèle personnalisées en remplaçant «DjangoModelPermissions».
TokenHasReadWriteScope
Il est destiné à être utilisé avec la classe ʻOAuthAuthentication ou ʻOAuth2Authentication.
Seules les méthodes sécurisées telles que «GET», «OPTIONS» ou «HEAD» sont autorisées si le jeton authentifié est autorisé en lecture.
Implémenter des autorisations personnalisées Remplacez une ou les deux méthodes suivantes dans BasePermission:
.has_permission(self,request,view).has_object_permission(self,request,view,obj)La méthode renvoie «True» si vous souhaitez attribuer l'accès à la requête, sinon elle renvoie «False».
De plus, si vous avez besoin de tester si une requête est une opération de lecture ou d'écriture, vous pouvez utiliser GET, ʻOPTIONS, HEADpour les constantes qui sont des tuples contenantSAFE_METHODS` comme suit: Vous devez vérifier la méthode de demande comme.
if request.method in permissions.SAFE_METHODS:
# Check permissions for read-only request
else:
# Check permissions for write request