django 오류 - Reason given for failure: CSRF cookie not set.

5848 단어 django
오늘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 안에 있는 MIDDLEWARECLASSES에 추가
    '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  element if the form is for an internal URL, e.g.:
    {% 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:

    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 csrf
      from django.shortcuts import render_to_response
      
      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.


    3. 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_exempt
      def 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를 도입한 것은 크로스 시트 Request Forgeries 공격을 피하기 위해서였고, 위의 해결 방법은 이django의 기능을 마침 금지했기 때문이다.그래서 앞으로 꼼꼼히 연구해 이 기능을 잃지 않는 전제에서 표를 성공적으로 제출해야 한다.
      끝나다
      다음으로 이동:http://blog.csdn.net/huangxiansheng1980/article/details/7482591
  • 좋은 웹페이지 즐겨찾기