更新2022

在CSRF攻击中，无辜的终端用户被攻击者欺骗，提交了一个他们不打算提交的web请求

选项1

from django.views.decorators.csrf import csrf_exempt
from django.http.response import JsonResponse


@csrf_exempt
def commentDeletePost(request):
    if request.is_ajax() and request.method == 'POST':
        try:
            comment = Comment.objects.get(pk=request.POST['pk'])
            if comment.author != request.user:
                return JsonResponse({'e': 'Forbidden'}, status=403) 
            comment.delete()
            return JsonResponse({}, status=200)
        execpt Comment.DoesNotExist:
            return JsonResponse({'e': 'Not Found'}, status=404)

选项2

<div id="csrf">
    {% csrf_token %}
</div>
<script type="text/javascript">
    window.crud = {
        commentDelete: function(
            pk, 
            success,
            error, 
        ){
            $.ajax({
                headers: {'X-CSRFToken': document.getElementById('csrf').querySelector('input').value},
                type: "POST", 
                url: "{% url 'comment-delete-post' %}",
                data: {
                    pk: pk,
                }, 
                success: success, 
                error: error,
            })
        }, 
    }
</script>

two options have its own advantage. First option will discard csrf token, which will not protecte your site from csrf attacks, but it will allow user to send more than one request with same Ajax function. the second option will restrict user to send one Ajax request only since csrf token can only be used once, but it is more secure. I personally prefer option 1, since Ajax functions such as like, star, unlike requires more than one Ajax call, and it is not a risky function to allow user call more than once.

如果你的表单在不使用JS的情况下可以在Django中正确地发布，你应该可以使用ajax逐步增强它，而不需要任何修改或混乱地传递csrf令牌。只需序列化整个表单，它将自动拾取所有表单字段，包括隐藏的csrf字段:

$('#myForm').submit(function(){
    var action = $(this).attr('action');
    var that = $(this);
    $.ajax({
        url: action,
        type: 'POST',
        data: that.serialize()
        ,success: function(data){
            console.log('Success!');
        }
    });
    return false;
});

我已经用Django 1.3+和jQuery 1.5+进行了测试。显然，这适用于任何HTML表单，而不仅仅是Django应用程序。

真正的解决方案

好的，我设法找到了问题所在。它存在于Javascript代码中(正如我在下面所建议的)。

你需要的是:

$.ajaxSetup({ 
     beforeSend: function(xhr, settings) {
         function getCookie(name) {
             var cookieValue = null;
             if (document.cookie && document.cookie != '') {
                 var cookies = document.cookie.split(';');
                 for (var i = 0; i < cookies.length; i++) {
                     var cookie = jQuery.trim(cookies[i]);
                     // Does this cookie string begin with the name we want?
                     if (cookie.substring(0, name.length + 1) == (name + '=')) {
                         cookieValue = decodeURIComponent(cookie.substring(name.length + 1));
                         break;
                     }
                 }
             }
             return cookieValue;
         }
         if (!(/^http:.*/.test(settings.url) || /^https:.*/.test(settings.url))) {
             // Only send the token to relative URLs i.e. locally.
             xhr.setRequestHeader("X-CSRFToken", getCookie('csrftoken'));
         }
     } 
});

而不是官方文档中发布的代码: https://docs.djangoproject.com/en/2.2/ref/csrf/

工作代码来自这个Django条目:http://www.djangoproject.com/weblog/2011/feb/08/security/

所以一般的解决方案是:“使用ajaxSetup处理程序而不是ajaxSend处理程序”。我不知道为什么会这样。但这对我来说很管用:)

以前的帖子(没有回答)

其实我也遇到了同样的问题。

它发生在更新到Django 1.2.5之后——在Django 1.2.4中AJAX POST请求没有错误(AJAX没有受到任何方式的保护，但它工作得很好)。

就像OP一样，我尝试了Django文档中发布的JavaScript代码片段。我使用的是jQuery 1.5。我还使用了“django.middleware.csrf”。CsrfViewMiddleware”中间件。

我试图遵循中间件代码，我知道它在这方面失败了:

request_csrf_token = request.META.get('HTTP_X_CSRFTOKEN', '')

然后

if request_csrf_token != csrf_token:
    return self._reject(request, REASON_BAD_TOKEN)

这个“if”为真，因为“request_csrf_token”为空。

基本上这意味着头文件没有被设置。所以这JS行有什么问题吗:

xhr.setRequestHeader("X-CSRFToken", getCookie('csrftoken'));

?

我希望提供的细节将有助于我们解决这个问题:)

这个问题是因为django希望cookie中的值作为表单数据的一部分传递回来。前一个答案中的代码是让javascript寻找cookie值并将其放入表单数据中。从技术角度来看，这是一种可爱的方式，但它看起来有点啰嗦。

在过去，我通过让javascript将令牌值放入post数据中更简单地做到了这一点。

如果在模板中使用{% csrf_token %}，则会发出一个包含该值的隐藏表单字段。但是，如果你使用{{csrf_token}}，你只会得到令牌的裸值，所以你可以在javascript中使用这个....

csrf_token = "{{ csrf_token }}";

然后，可以在散列中包含所需的键名，然后将其作为数据提交给ajax调用。

公认的答案很可能是在转移注意力。Django 1.2.4和1.2.5之间的区别在于AJAX请求需要CSRF令牌。

我在Django 1.3上遇到了这个问题，这是由于CSRF cookie一开始就没有设置造成的。除非必须，否则Django不会设置cookie。因此，在Django 1.2.4上运行的纯ajax或重度ajax站点可能永远不会向客户端发送令牌，然后需要令牌的升级将导致403错误。

理想的解决方法是: http://docs.djangoproject.com/en/dev/ref/contrib/csrf/#page-uses-ajax-without-any-html-form 但是您必须等到1.4版本，除非这只是文档与代码同步

Edit

还要注意的是，Django文档在jQuery 1.5中指出了一个bug，所以确保你使用的是1.5.1或更高版本的Django建议代码: https://docs.djangoproject.com/en/dev/ref/csrf/#ajax

{% csrf_token %}在<form></form>内放置html模板

翻译过来就是:

<input type='hidden' name='csrfmiddlewaretoken' value='Sdgrw2HfynbFgPcZ5sjaoAI5zsMZ4wZR' />

所以为什么不像这样在你的JS中grep它:

token = $("#change_password-form").find('input[name=csrfmiddlewaretoken]').val()

然后传递它，例如做一些POST，比如:

$.post( "/panel/change_password/", {foo: bar, csrfmiddlewaretoken: token}, function(data){
    console.log(data);
});