Aby skorzystać z ochrony CSRF w swoich widokach, wykonaj następujące kroki:
\nThe CSRF middleware is activated by default in the MIDDLEWARE\nsetting. If you override that setting, remember that\n'django.middleware.csrf.CsrfViewMiddleware' should come before any view\nmiddleware that assumes that CSRF attacks have been dealt with.
Jeśli go wyłączyłeś, co nie jest zalecane, możesz użyć csrf_protect() na poszczególnych widokach, które chcesz chronić (zobacz poniżej).
W dowolnym szablonie, który używa formularza POST, użyj tagu csrf_token wewnątrz elementu <form> jeśli formularz jest dla wewnętrznego adresu URL, np:
<form method="post">{% csrf_token %}\nNie należy tego robić w przypadku formularzy POST, które kierują do zewnętrznych adresów URL, ponieważ spowodowałoby to wyciek tokena CSRF, prowadząc do luki.
\nW odpowiednich funkcjach widoku, upewnij się, że RequestContext jest używany do renderowania odpowiedzi, tak aby {% csrf_token %} działał poprawnie. Jeśli używasz funkcji render(), widoków generycznych, lub aplikacji contrib, jest już zawarta, ponieważ wszystkie one używają RequestContext.
Podczas gdy powyższa metoda może być użyta dla żądań AJAX POST, ma ona pewne niedogodności: musisz pamiętać, aby przekazać token CSRF jako dane POST z każdym żądaniem POST. Z tego powodu istnieje alternatywna metoda: na każdym XMLHttpRequest, ustaw niestandardowy nagłówek X-CSRFToken (określony przez ustawienie CSRF_HEADER_NAME) na wartość tokena CSRF. Jest to często łatwiejsze, ponieważ wiele frameworków JavaScript zapewnia haki, które umożliwiają ustawienie nagłówków na każdym żądaniu.
Najpierw musisz uzyskać token CSRF. Jak to zrobić, zależy od tego, czy ustawienia CSRF_USE_SESSIONS i CSRF_COOKIE_HTTPONLY są włączone.
Na koniec będziesz musiał ustawić nagłówek na swoim żądaniu AJAX. Korzystanie z API fetch():
\nconst request = new Request(\n /* URL */,\n {\n method: 'POST',\n headers: {'X-CSRFToken': csrftoken},\n mode: 'same-origin' // Do not send CSRF token to another domain.\n }\n);\nfetch(request).then(function(response) {\n // ...\n});\nBackend szablonów Django Jinja2 dodaje { csrf_input }} do kontekstu wszystkich szablonów, co jest odpowiednikiem {% csrf_token %} w języku szablonów Django. Na przykład:
<form method="post">{{ csrf_input }}\nZamiast dodawać CsrfViewMiddleware jako ogólną ochronę, możesz użyć dekoratora csrf_protect`(), który ma dokładnie taką samą funkcjonalność, na poszczególnych widokach, które potrzebują ochrony. Musi być używany zarówno na widokach, które wstawiają token CSRF do wyjścia, jak i na tych, które akceptują dane formularza POST. (Często są to te same funkcje widoku, ale nie zawsze).
Używanie dekoratora samego w sobie jest niezalecane, ponieważ jeśli zapomnisz go użyć, będziesz miał dziurę w zabezpieczeniach. Strategia „pasa i szelek” polegająca na używaniu obu jest w porządku i poniesie minimalny narzut.
\nDomyślnie, odpowiedź «403 Forbidden» jest wysyłana do użytkownika, jeśli przychodzące żądanie nie przejdzie kontroli przeprowadzonej przez CsrfViewMiddleware. Powinno to być widoczne tylko wtedy, gdy istnieje prawdziwe Cross Site Request Forgery, lub gdy z powodu błędu programistycznego, token CSRF nie został dołączony do formularza POST.
Strona błędu nie jest jednak zbyt przyjazna, więc możesz chcieć zapewnić własny widok do obsługi tego warunku. Aby to zrobić, ustaw CSRF_FAILURE_VIEW.
Niepowodzenia CSRF są logowane jako ostrzeżenia do :ref:`django.security.csrf ` logger.
\nJeśli tag szablonu csrf_token jest użyty przez szablon (lub funkcja get_token jest wywołana w inny sposób), CsrfViewMiddleware doda ciasteczko i nagłówek Vary: Cookie do odpowiedzi. Oznacza to, że middleware będzie grał dobrze z cache middleware, jeśli jest używany zgodnie z instrukcją (UpdateCacheMiddleware idzie przed wszystkimi innymi middleware).
Jednakże, jeśli używasz dekoratorów cache na poszczególnych widokach, CSRF middleware nie będzie jeszcze w stanie ustawić nagłówka Vary lub CSRF cookie, a odpowiedź będzie buforowana bez żadnego z nich. W tym przypadku, na każdym widoku, który będzie wymagał wstawienia tokena CSRF powinieneś użyć najpierw dekoratora django.views.decorators.csrf.csrf_protect():
from django.views.decorators.cache import cache_page\nfrom django.views.decorators.csrf import csrf_protect\n\n\n@cache_page(60 * 15)\n@csrf_protect\ndef my_view(request): ...\nJeśli używasz widoków opartych na klasach, możesz odwołać się do Decorating widoków opartych na klasach.
\nThe CsrfViewMiddleware will usually be a big hindrance to testing view\nfunctions, due to the need for the CSRF token which must be sent with every\nPOST request. For this reason, Django’s HTTP client for tests has been modified\nto set a flag on requests which relaxes the middleware and the csrf_protect\ndecorator so that they no longer rejects requests. In every other respect (e.g.\nsending cookies etc.), they behave the same.
If, for some reason, you want the test client to perform CSRF\nchecks, you can create an instance of the test client that enforces\nCSRF checks:
\n>>> from django.test import Client\n>>> csrf_client = Client(enforce_csrf_checks=True)\nCertain views can have unusual requirements that mean they don’t fit the normal\npattern envisaged here. A number of utilities can be useful in these\nsituations. The scenarios they might be needed in are described in the\nfollowing section.
\nMost views requires CSRF protection, but a few do not.
\nSolution: rather than disabling the middleware and applying csrf_protect to\nall the views that need it, enable the middleware and use\ncsrf_exempt().
CsrfViewMiddleware.process_view() is not usedLink to this heading#There are cases when CsrfViewMiddleware.process_view may not have run\nbefore your view is run - 404 and 500 handlers, for example - but you still\nneed the CSRF token in a form.
Solution: use requires_csrf_token()
There may be some views that are unprotected and have been exempted by\ncsrf_exempt, but still need to include the CSRF token.
Solution: use csrf_exempt() followed by\nrequires_csrf_token(). (i.e.\nrequires_csrf_token should be the innermost decorator).
A view needs CSRF protection under one set of conditions only, and mustn’t have\nit for the rest of the time.
\nSolution: use csrf_exempt() for the whole\nview function, and csrf_protect() for the\npath within it that needs protection. Example:
from django.views.decorators.csrf import csrf_exempt, csrf_protect\n\n\n@csrf_exempt\ndef my_view(request):\n @csrf_protect\n def protected_path(request):\n do_something()\n\n if some_condition():\n return protected_path(request)\n else:\n do_something_else()\nA page makes a POST request via AJAX, and the page does not have an HTML form\nwith a csrf_token that would cause the required CSRF cookie to be sent.
Solution: use ensure_csrf_cookie() on the\nview that sends the page.
Because it is possible for the developer to turn off the\nCsrfViewMiddleware, all relevant views in contrib apps use the\ncsrf_protect decorator to ensure the security of these applications against\nCSRF. It is recommended that the developers of other reusable apps that want\nthe same guarantees also use the csrf_protect decorator on their views.