今天练习django的form的提交。当提交表单的时候，出现了
Forbidden (403)
CSRF verification failed. Request aborted.
Help
Reason given for failure:
CSRF cookie not set.
In general, this can occur when there is a genuine Cross Site Request Forgery, or when Django's CSRF mechanism has not been used correctly. For POST forms, you need to ensure:
- Your browser is accepting cookies.
- The view function uses
RequestContext for the template, instead of Context. - In the template, there is a
{% csrf_token %} template tag inside each POST form that targets an internal URL. - If you are not using
CsrfViewMiddleware, then you must use csrf_protect on any views that use the csrf_token template tag, as well as those that accept the POST data.
You're seeing the help section of this page because you have DEBUG = True in your Django settings file. Change that to False, and only the initial error message will be displayed.
You can customize this page using the CSRF_FAILURE_VIEW setting.
从网上查到很多人说
在settings.py里面的MIDDLEWARE_CLASSES 中加入
'django.middleware.csrf.CsrfResponseMiddleware',
但是我的问题还是依旧，可是很多人说他们的问题就是这样解决的。后来知道是因为他们用的是1.2的版本，而我用的1.4版本，
后来去到官网：
https://docs.djangoproject.com/en/1.2/ref/contrib/csrf/
参照它说的：
To enable CSRF protection for your views, follow these steps:
Add the middleware'django.middleware.csrf.CsrfViewMiddleware' to your list ofmiddleware classes, MIDDLEWARE_CLASSES. (It should comebeforeCsrfResponseMiddleware if that is being used, and before anyview middleware that assume that CSRF attacks have been dealt with.)
Alternatively, you can use the decoratordjango.views.decorators.csrf.csrf_protect on particular views youwant to protect (see below).
In any template that uses a POST form, use the csrf_token tag insidethe <form> element if the form is for an internal URL, e.g.:
<form action="" method="post">{% csrf_token %}This should not be done for POST forms that target external URLs, sincethat would cause the CSRF token to be leaked, leading to a vulnerability.
In the corresponding view functions, ensure that the'django.core.context_processors.csrf' context processor isbeing used. Usually, this can be done in one of two ways:
Use RequestContext, which always uses'django.core.context_processors.csrf' (no matter what yourTEMPLATE_CONTEXT_PROCESSORS setting). If you are usinggeneric views or contrib apps, you are covered already, since theseapps use RequestContext throughout.
Manually import and use the processor to generate the CSRF token andadd it to the template context. e.g.:
from django.core.context_processors import csrffrom django.shortcuts import render_to_responsedef my_view(request): c = {} c.update(csrf(request)) # ... view code here return render_to_response("a_template.html", c)You may want to write your own render_to_response wrapper thattakes care of this step for you.
The utility script extras/csrf_migration_helper.py can help to automate thefinding of code and templates that may need to be upgraded. It contains fullhelp on how to use it.
但是问题依旧，后来又看到另外一种方式在这个网站上：
o manually exclude a view function from being handled by either of the two CSRFmiddleware, you can use the csrf_exempt decorator, found in thedjango.views.decorators.csrf module. For example:
from django.views.decorators.csrf import csrf_exempt@csrf_exemptdef my_view(request): return HttpResponse('Hello world')Like the middleware, the csrf_exempt decorator is composed of two parts: acsrf_view_exempt decorator and a csrf_response_exempt decorator, foundin the same module. These disable the view protection mechanism(CsrfViewMiddleware) and the response post-processing(CsrfResponseMiddleware) respectively. They can be used individually ifrequired.
终于把这个问题解决了。
其实我是绕开了这个问题，因为django之所以引进CSRF是为了避免Cross Site Request Forgeries攻击，而上面的解决方法恰好禁止掉这个django的功能。所以日后还得仔细研究下，在不禁掉这个功能的前提下成功的提交表单。
完
