To re-produce this bug, make a PUT or DELETE request to an endpoint that
you are using the csrf_exempt decorator (in my use-case its not from the
browser but from a component using its own Basic Auth with Django) and you
will get a 403.
This is due to code in the line 161 of the process_view function in
middleware/csrf.py which checks if the cookie is missing and if so it
rejects the request. The comments say that it is for POST
requests only, so I'm unsure whether the intention was for PUT and DELETE
to fall under that category in which case I can add a patch to make the
comments
explicitly mention PUT and DELETE. Otherwise I will add a patch so that
PUT and DELETE are allowed through to the view which is only a few lines.
Can anyone clarify for me whether it is by intention that PUT and DELETE
also fail here if they don't have a CSRF cookie set?
Thanks
--
Ticket URL: <https://code.djangoproject.com/ticket/23800>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
* status: new => closed
* needs_better_patch: => 0
* resolution: => invalid
* needs_tests: => 0
* needs_docs: => 0
Comment:
During `POST` request, the `CSRF` token is taken from `request.POST`, all
other "unsafe" methods, `PUT`, `PATCH`, `DELETE`, should set the
`X-CSRFToken` as described in
[https://docs.djangoproject.com/en/1.7/ref/contrib/csrf/#ajax
documentation].
--
Ticket URL: <https://code.djangoproject.com/ticket/23800#comment:1>