title: Django: CSRF middleware and mixed POST/GET forms
body: <p>I would like to crate a form whith two submit buttons: <code>Save</code>, let's say, and <code>Back to edit</code>. (The form is meant for a preview / confirm view of stuff that is currently being edited).</p>
  
  <p>For obvious reasons the <code>Save</code> button has a <code>formaction</code> attribute with value <code>post</code> and the other button <code>get</code>. For the <code>post</code> action to work, I include the usual <code>csrfmiddlewaretoken</code> in the form. </p>
  
  <p>So far all works well, the only problem is that the <code>csrfmiddlewaretoken</code> value is now included in the GET requests (which seems to be discouraged for security reasons). </p>
  
  <p>Currently I add some custom javascript that finds all submit buttons with <code>get</code> action and adds a click handler that removes the <code>csrfmiddlewaretoken</code> from the field before submit. This seems a rather wierd and roundabaout way to do things. </p>
  
  <p>Question: Is there a better / more standard / more stable way to handle this situation?</p>
  
  <p><strong>Edit:</strong> Why do I want to use get requests for some form actions? </p>
  
  <p>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). </p>
  
  <p>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.</p>
  
  <p>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.</p>