Package: django-session-csrf-per-view
What is this?django-session-csrfis an alternative implementation of Django’s CSRF
protection that does not use cookies. Instead, it maintains the CSRF token on
the server using Django’s session backend. The csrf token must still be
included in all POST requests (either withcsrfmiddlewaretokenin the form or
with theX-CSRFTOKENheader).InstallationFrom PyPI:pip install django-session-csrf-per-viewFrom github:git clone git://github.com/mozilla/django-session-csrf.gitReplacedjango.core.context_processors.csrfwithsession_csrf.context_processorin yourTEMPLATE_CONTEXT_PROCESSORS:TEMPLATE_CONTEXT_PROCESSORS = (
    ...
    'session_csrf.context_processor',
    ...
)Replacedjango.middleware.csrf.CsrfViewMiddlewarewithsession_csrf.CsrfMiddlewarein yourMIDDLEWARE_CLASSESand make sure it is listed after the AuthenticationMiddleware:MIDDLEWARE_CLASSES = (
    ...
    'django.contrib.auth.middleware.AuthenticationMiddleware',
    ...
    'session_csrf.CsrfMiddleware',
    ...
)Then we have to monkeypatch Django to fix the@csrf_protectdecorator:import session_csrf
session_csrf.monkeypatch()Make sure that’s in something like your rooturls.pyso the patch gets
applied before your views are imported.Differences from Djangodjango-session-csrfdoes not assign CSRF tokens to anonymous users because
we don’t want to support a session for every anonymous user. Instead, views
that need anonymous forms can be decorated with@anonymous_csrf:from session_csrf import anonymous_csrf

@anonymous_csrf
def login(request):
    ...anonymous_csrfuses the cache to give anonymous users a lightweight
session. It sends a cookie to uniquely identify the user and stores the CSRF
token in the cache.  It can be controlled through these settings:ANON_COOKIEthe name used for the anonymous user’s cookieDefault:anoncsrfANON_TIMEOUTthe cache timeout (in seconds) to use for the anonymous CSRF tokensDefault:60 * 60 * 2  # 2 hoursNote that by default Django uses local-memory caching, which will not
work with anonymous CSRF if there is more than one web server thread.
To use anonymous CSRF, you must configure a cache that’s shared
between web server instances, such as Memcached.  See theDjango cache
documentationfor more information.If you only want a view to have CSRF protection for logged-in users, you can
use theanonymous_csrf_exemptdecorator. This could be useful if the
anonymous view is protected through a CAPTCHA, for example.from session_csrf import anonymous_csrf_exempt

@anonymous_csrf_exempt
def protected_in_another_way(request):
    ...If you want all views to have CSRF protection for anonymous users, use
the following setting:ANON_ALWAYSalways provide CSRF protection for anonymous usersDefault: FalsePer-action CSFR tokensFor using per-action CSRF tokens you need decorate your view:fromsession_csrf.decoratorsimportper_view_csrf@per_view_csrfdefyour_view(request):passOr for class-based views:fromdjango.views.genericimportTemplateViewfromsession_csrf.mixinsimportPerViewCsrfMixinclassYourView(PerViewCsrfMixin,TemplateView):passAnd add template tag in your template:{%loadsession_csrf%}<form>{%per_view_csrf"app.views.your_view"%}</form>Why do I want this?Your site is on a subdomain with other sites that are not under your
control, so cookies could come from anywhere.You’re worried about attackers using Flash to forge HTTP headers.You’re tired of requiring a Referer header.Why don’t I want this?Storing tokens in sessions means you have to hit your session store more
often.It’s a little bit more work to CSRF-protect forms for anonymous users.