Preserve form state while keeping the protections in SA-CORE-2020-004

The error is actually (emphasis, mine):

The form has become outdated. Press the back button, copy any unsaved work in the form, and then reload the page.

This issue is missing a key bit of detail without that because the steps to reproduce describe not following that instruction. Is this appropriate as a bug report given that fact.

Wouldn't this be a general improvement to the form system to reload the stored form values in this event rather than some specific improvement tot he permissions form? But the existence of the error message suggests that reloading the stored values in this situation is difficult or impossible.

The most recent behavior change was in 357efb6c3377, which is for Drupal core - Critical - Cross Site Request Forgery - SA-CORE-2020-004 → . The error message was changed in that release to indicate the proper way not to lose the form post.

I am postponing this to get a confirmation that following the error instructions eliminates the issue. Even so, we could take it from there to discover some kind of way to retain the form data securely. Let's get that info first.

If the site administrator correctly follows the instructions (presses the back button, copies down all of the permissions checkbox values, reloads the page, then updates all of the permissions checkboxes again), then there is no problem — the permissions are correctly updated.

However, I do think is a usability concern with this particular form: if the site administrator overlooks the instructions and submits the current page (rather than using the browser's back button), then, with a single click, all of the site's permissions are revoked. My intention in raising this concern is to help reduce the likelihood of that incident recurring.

For many other forms (creating a node, for example), it is very obvious if the form has been emptied: by default, Drupal doesn't allow you to create a node with an empty title, and if you were to follow the same steps in the issue body with /node/add/page instead of /admin/people/permissions, then form validation fails, and there is no adverse effect. But since the permissions form is very large (and typically sparse) it's easy to overlook that the form state has been cleared, and since Drupal allows submitting a fully empty permissions form, it's easy for that form-state-clearing to unintentionally revoke all of the site's permissions.