django錯誤 - Reason given for failure: CSRF cookie..

今天練習django的form的提交。當提交表單的時候,出現了html


Forbidden (403)

CSRF verification failed. Request aborted.web

Help

Reason given for failure:django

    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:api

  • Your browser is accepting cookies.cookie

  • The view function uses RequestContext for the template, instead of Context.app

  • In the template, there is a {% csrf_token %} template tag inside each POST form that targets an internal URL.ide

  • 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.post

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.ui


從網上查到不少人說

在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:

  1. 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).

  2. 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.

  3. 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:

    1. 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.

    2. 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_response
    3. def 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的功能。因此往後還得仔細研究下,在不由掉這個功能的前提下成功的提交表單。



相關文章
相關標籤/搜索