La méthode POST retourne toujours 403 Interdit

J'ai lu Django - CSRF échec de la vérification de et plusieurs questions (et réponses) liées à django et la méthode POST. L'un des meilleurs-mais-pas-de travail-pour moi, la réponse est https://stackoverflow.com/a/4707639/755319

Toutes les réponses suggèrent au moins 3 choses:

Utilisation RequestContext en tant que troisième paramètre de render_to_response_call
Ajouter {% csrf_token %} dans chaque formulaire avec la méthode POST
Vérifier la MIDDLEWARE_CLASSES dans settings.py

J'ai fait exactement comme il est suggéré, mais l'erreur est apparu. J'utilise django 1.3.1 (à partir d'ubuntu 12.04 référentiel) et python 2.7 (par défaut d'ubuntu)

C'est mon point de Vue:

# Create your views here.
from django.template import RequestContext
from django.http import HttpResponse
from django.shortcuts import render_to_response
from models import BookModel

def index(request):
    return HttpResponse('Welcome to the library')

def search_form(request):
    return render_to_response('library/search_form.html')

def search(request):
    if request.method=='POST':
        if 'q' in request.POST:
            q=request.POST['q']
            bookModel = BookModel.objects.filter(title__icontains=q)
            result = {'books' : bookModel,}
            return render_to_response('library/search.html', result, context_instance=RequestContext(request))
        else:
            return search_form(request)
    else:
        return search_form(request)

et c'est mon modèle (search_form.html):

{% extends "base.html" %}
{% block content %}
<form action="/library/search/" method="post">
    {% csrf_token %} 
    <input type="text" name="q">
    <input type="submit" value="Search">
</form>
{% endblock %}

J'ai redémarré le serveur, mais 403 forbidden erreur est toujours là, en disant que CSRF échec de la vérification.

J'ai 2 questions:

Comment corriger cette erreur?
Pourquoi est-il si difficile de faire un "POST" dans django, je veux dire, est-il une raison particulière de faire en sorte verbose (je viens de PHP, et n'a jamais trouvé un tel problème avant)?

source d'informationauteur goFrendiAsgard

3

Essayer de mettre RequestContext dans le search_form vue render_to_response:
```
context_instance=RequestContext(request)
```

J'ai peut-être tort cependant j'ai trouvé les solutions ci-dessus plutôt complexe.

ce qui a fonctionné pour moi a été tout simplement y compris mon jeton csrf dans ma requête post.

$.ajax({
    type: "POST",
    url: "/reports/",
    data: { csrfmiddlewaretoken: "{{ csrf_token }}",   //< here 
            state:"inactive" 
          },
    success: function() {
        alert("pocohuntus")
        console.log("prototype")
    }
})

La façon la plus simple pour éviter de tels problèmes est d'utiliser le render raccourci.

from django.shortcuts import render
# .. your other imports

def search_form(request):
    return render(request, 'library/search_form.html')

def search(request):
    q = request.GET.get('q')
    results = BookModel.objects.all()
    if q:
        results = results.filter(title__icontains=q)
    return render(request, 'library/search.html', {'result': results})

2

La réponse est 403 bcoz,
django nécessite un jeton csrf (inclus dans le message de données) dans chaque POST que vous faites.

Il y a différentes façons de le faire, tels que:

Acquérir le jeton de cookies et de la méthode a été expliqué dans l'article entrez description du lien ici

ou

Vous pouvez y accéder depuis les DOM à l'aide de {{ csrf_token }}, disponible dans le modèle

Maintenant en utilisant la deuxième méthode:
```
var post_data = {
  ...
  'csrfmiddlewaretoken':"{{ csrf_token }}"
  ...
}
$.ajax({
  url:'url',
  type:'POST'
  data:post_data,
  success:function(data){
    console.log(data);
  },
  error:function(error){
    console.log(error);
  }
});
```
1

Cette réponse est pour les personnes qui peuvent rencontrer ce même problème dans le futur.

Le CSRF {{csrf_token}} balise de modèle qui est nécessaire pour les formulaires dans Django prévenir contre Cross Site Request Forgeries. CSRF rend-il possible pour un site malveillant qui a été visitée par un navigateur du client à en faire la demande à votre propre serveur. D'où la csrf_token fournis par django le rend simple pour votre django serveur de site et d'être protégé contre ce type d'attaque malveillante. Si votre formulaire n'est pas protégé par csrf_token, django retourne un 403 forbidden page. C'est une forme de protection pour votre site web, en particulier lorsque le jeton n'a rien laissé intentionnellement.

Mais il existe des cas où un site django ne voulez pas protéger ses formes à l'aide de la csrf_token. Par exemple, j'ai développé une application USSD et une fonction de vue est nécessaire pour recevoir une requête POST à partir de l'USSD API. Il convient de noter que le POSTE demande n'a pas été à partir d'un formulaire sur le client, donc le risque de CSRF impossible, puisqu'un site malveillant ne peut pas présenter de demande. Le POSTE demande est reçue lorsqu'un utilisateur compose un code USSD et pas quand un formulaire est soumis.

En d'autres termes, il existe des situations où une fonction aurez besoin pour obtenir une demande POST et il n'y aurait pas la nécessité de {{csrf_token}}.

Django nous offre un décorateur @csrf_exempt. Ce décorateur marques de vue comme étant exempte de la protection assurée par le middleware.
```
from django.views.decorators.csrf import csrf_exempt
from django.http import HttpResponse

@csrf_exempt
def my_view(request):
    return HttpResponse('Hello world')
```
Django fournit également un autre décorateur qui remplit la même fonction avec {{csrf_token}}mais il n'est pas de rejeter les requêtes entrantes. Ce décorateur est @requires_csrf_token. Par exemple:
```
@requires_csrf_token
def my_view(request):
    c = {}
    # ...
    return render(request, "a_template.html", c)
```
La dernière décorateur qui sera mentionné dans ce post fait exactement la même chose comme {{csrf_token}} et il est appelé @csrf_protect. Cependant, l'utilisation de cette décorateur par lui-même n'est pas le plus pratique, car vous risquez d'oublier de l'ajouter à votre point de vue. Par exemple:
```
@csrf_protect
def my_view(request):
    c = {}
    # ...
    return render(request, "a_template.html", c)
```
Ci-dessous sont quelques-uns des liens qui vont guider et expliquer mieux.

https://docs.djangoproject.com/en/1.7/ref/contrib/csrf/#module-django.views.decorators.csrf

https://docs.djangoproject.com/en/1.7/ref/contrib/csrf/

http://www.squarefree.com/securitytips/web-developers.html#CSRF
0

Vous pouvez également utiliser
```
direct_to_template(request, 'library/search.html', result) 
```
au lieu de
```
render_to_response('library/search.html', result, context_instance=RequestContext(request))
```
parce que direct_to_template ajoute RequestContext automatiquement. Mais notez que direct_to_template va être obsolète et django offres pour l'utilisation de CBV TemplateView à la place.

RequestContext vous permet de contexte de l'utilisation des processeurs. Et c'est de votre faute: {% csrf_token %} outputed chaîne vide et vous avez obtenu 403.

Vous devez utiliser RequestContext avec votre réponse

par exemple
dans view.py fichier

from django.template import RequestContext

def home(request):
    return render_to_response('home.html',RequestContext(request, {}))

Vous devez vous connecter pour publier un commentaire.