Если POST-запросы по умолчанию защищены csrf. Какова цель использования @method_decorator(csrf_protect) в Django?
Я думаю, что все запросы POST, PUT, DELETE по умолчанию защищены CSRF в DRF. Но в некоторых обучающих видеороликах я видел, что они используют @method_decorator(csrf_protect) в некоторых представлениях на основе классов с запросами POST и DELETE, поэтому я сделал то же самое.
Но теперь я думаю, какова цель этого, если эти запросы по умолчанию защищены CSRF?
@method_decorator(csrf_protect, name='dispatch')
class LogoutView(APIView):
def post(self, request, format=None):
try:
auth.logout(request)
return Response({'success': 'Logged out.'})
except Exception as e:
print(e)
return Response({'error': 'Something went wrong.'})
Что это значит?
Ответы 1
Да, POST-запросы обычно защищены от подделки CSRF. Но это не сам Django, а CsrfViewMiddleware [Django-doc] . Таким образом, это промежуточное ПО должно находиться в настройке ПРОМЕЖУТОЧНОЕ ОБЕСПЕЧЕНИЕ [Django-doc] , и по умолчанию оно так и есть. Но вы можете удалить промежуточное программное обеспечение, например, если не хотите защищать его по умолчанию. В этом случае вы можете использовать декоратор @csrf_protect [Django-doc], чтобы сделать это только для определенного набора представлений.
Другими словами, вы можете добавить CsrfViewMiddleware к настройке MIDDLEWARE (и для нового проекта Django это так), и тогда все представления по умолчанию будут защищены CSRF, если вы не укажете это с помощью декоратора @csrf_exempt [Django -doc], или вы можете удалить промежуточное программное обеспечение и помечать только определенные представления, защищенные CSRF.
Отключение CSRF является обычным явлением для API, поскольку они обычно не работают с файлами cookie. Поэтому, если вы создаете приложение Django, которое, например, будет обслуживать приложение React или Vue, нередко удаляется значок CsrfViewMiddleware.
Они защищены промежуточным программным обеспечением.