> If this is a terrible Idea, I would like to know why POST requests are the > only methods that allows the CSRF token to be sent along with the payload > directly instead of setting the token in the Header.
That behaviour is because GET and POST are the only two methods supported by browsers for HTML form submission. In the case of standard HTML forms it's not possible to add extra headers, so the only way to include a CSRF token is to include it in the payload. For any other method you'll necessarily be making an AJAX request (or some other programmatic interaction outside of a browser) in which case adding the CSRF token to the headers is possible, and preferable. Reasons that you might not want to allow the CSRF token in the payload include: * What do you do about non-form encoded payloads. Do you allow a CSRF token in JSON? What about JSON where the top level element isn't an object but is a list, or a primitive such as a number? What about other encoding such as YAML or XML? * DELETE requests don't typically include request payloads. Clients may not handle payloads on DELETE and might coerce data to query parameters in that case. Servers and intermediaries might not rely payloads on DELETE requests to the application. Another way around of expressing this is that we don't really want a CSRF token in the payload in any cases, it's just that the constraints of HTML forms in browsers means it's the only way we can do it there. - T :) -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/3b20b364-5ffb-4f63-9321-46b3b3633f70%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
