Introduction to Python's CSRF

Django provides users with the ability to prevent cross-site request forgery, which is accomplished through middleware django.middleware.csrf.CsrfViewMiddleware. For Django, the ability to set up anti-cross-site request forgery is divided into global and local.

Global:

Middleware Django.middleware.csrf.CsrfViewMiddleware

Local:

@csrf_protect, force the anti-cross-site request forgery feature for the current function, even if the global middleware is not set in Settings.

@csrf_exempt, cancels the current function of anti-cross-site request forgery, even if the global middleware is set in Settings.

Note: from DJANGO.VIEWS.DECORATORS.CSRF import Csrf_exempt,csrf_protect

Principle

When submitting data with a post, Django checks to see if there is a random string of csrf, and if it does not, it will be an error, which is why we have commented on it before, as follows:

Generate this random string in Django internal support

Submit via Form

You need to add {%csrf_token%} inside the form form

So when you look at the source of the page, you can see that there is an input in the form is hidden

Summary principle: When the user accesses the login page, generates a random string of csrf, and the cookie also holds the random string, when the user submits the data again with this random string commit, if there is no such random string can not be submitted successfully

Cookies are stored in csrftoken such as

Submit via Ajax

Because Csrftoken is also present in the cookie, it can be passed in JS:

$.cooke ("Cstftoken") gets

If the data is submitted via Ajax, the Csrftoken submitted here is stored in the request header, and a dictionary type of data is required, i.e. a key is required at this time.

In views, in the login function: From django.conf import settings, then prints print (settings. Csrf_header_name)

Here's a question to be aware of, The settings imported here is not the settings.py file we see under the project file, here is a global settings configuration, and when we configure it in settings.py in the project directory, the configuration we add overrides the configuration in the global settings

Print (settings. Csrf_header_name) The content printed is: Http_x_csrftoken

The Http_x_csrftoken here is that Django adds the HTTP_ in front of the x_csrf, so the actual pass is X_csrftoken, and the Ajax of the front page cannot be underlined so it is X_csrftoken

Here's what's written in front-end Ajax:

    $ ("#btn1"). Click (function () {        $.ajax ({            URL: "/login/",            Type: "POST",            data:{"usr": "Root", "pwd": " 123 "},            headers:{" X-csrftoken ": $.cookie (" Csrftoken ")},            success:function (ARG) {            }        })    })

But if there is more than one AJAX request in the page, add headers information to each AJAX, so you can add it to all Ajax in the following way

        $.ajaxsetup ({            beforesend:function (xhr,settings) {                xhr.setrequestheader ("X-csrftoken", $.cookie (" Csrftoken "))            }        );

This will execute this method before committing Ajax, adding this csrftoken to all Ajax.

The XHR here is shorthand for XMLHttpRequest, which is what Ajax calls this method.

If you want to implement when the Get mode does not need to commit csrftoken, when the post is required, the code to achieve this effect is as follows:

function Csrfsafemethod (method) {            //These HTTP methods does not require CSRF protection            return (/^ (get| head| options| TRACE) $/.test (method));        }        $.ajaxsetup ({            beforesend:function (XHR, settings) {                if (!csrfsafemethod (settings.type) &&!) This.crossdomain) {                    xhr.setrequestheader ("X-csrftoken", Csrftoken);}}        );

This is achieved when the get| head| options| Trace These methods are requested without the need to submit Csrftoken

Introduction to Python's CSRF