0

I would like to crate a form whith two submit buttons: Save, let's say, and Back to edit. (The form is meant for a preview / confirm view of stuff that is currently being edited).

For obvious reasons the Save button has a formaction attribute with value post and the other button get. For the post action to work, I include the usual csrfmiddlewaretoken in the form.

So far all works well, the only problem is that the csrfmiddlewaretoken value is now included in the GET requests (which seems to be discouraged for security reasons).

Currently I add some custom javascript that finds all submit buttons with get action and adds a click handler that removes the csrfmiddlewaretoken from the field before submit. This seems a rather wierd and roundabaout way to do things.

Question: Is there a better / more standard / more stable way to handle this situation?

Edit: Why do I want to use get requests for some form actions?

Well, I would like to stick to the rule to use POST requests (only) for requests that change data (and in that case respond with a redirect).

As an example, think of a form where the user can edit ("page A") some fields, and then can press "preview" (a GET action), which leads "page B" where the same form is presented, but readonly, with a preview image generated by the system. If the user is happy, they can press "save" (a POST action) which will actually save the data, or they can press "back" (a GET action, similar to the Browser's back button), to continue editing the data. I would not be happy to implement this "Back" operation as POST, as this messes up the interaction with the actual Browser back button etc.

In this simple example, one could of course ask the user to use the browser back button instead of a form button, or (probably?) use javascript to simulate a browser back. But with slightly more complicated flow control a simple "back" is not an option.

Jakob
  • 238
  • 3
  • 12

1 Answers1

1

The problem is that you send GET request from the form that contains your CSRF token. I would rather recommend PUT request than GET request. The CSRF token value is not exposed on the URL because the PUT request allows the body value to be passed.

About HTTP PUT method

Jrog
  • 1,469
  • 10
  • 29
  • Thank you for that suggestion. It indeed seems that semantically `PUT` would be the perfect solution. However, I am a bit worried whether there is stable support for `PUT` in django? The documentation routinely only mentions `POST` and `GET`. To start with, would I find the `PUT` data in `request.put` or in `request.post`? Will the various middleware work with `PUT`? Will webtest etc?. At the very least I would have to change some of my own code where I expect either `POST` or `GET`... – Jakob Feb 11 '19 at 23:02
  • This [question](https://stackoverflow.com/questions/4994789/django-where-are-the-params-stored-on-a-put-delete-request) will help you. @Jakob – Jrog Feb 11 '19 at 23:42