Come together with the global Drupal community in Rotterdam, 28 Sept – 1 Oct 2026. Sessions, contribution, connection, and Early Bird savings until 8 June.Problem/Motivation
If the permissions form token becomes invalid, the regenerated form surprisingly has all permissions checkboxes unchecked. If the administrator then clicks "Save permissions" (without closely inspecting the humongous permissions form), then all of the site's permissions will be revoked. This caused an outage on a production website (since all permissions had been unexpectedly revoked, so unprivileged users were unable to access content).
Steps to reproduce
- On a disposable test site, log in as an Administrator
- Open /admin/people/permissions in one tab
- In another tab, log out, then log back in as the same Administrator user
- Back in the first tab, click "Save permissions"
- Drupal shows the "The form has become outdated" error
- Note that all of the permissions checkboxes (except the Administrator column) are unchecked
- Click "Save permissions" again — this time Drupal allows the form submission, and all of the site's permissions have been revoked 💥
Proposed resolution
When showing the "The form has become outdated" error, the permissions form should be populated with the active set of permissions (instead of a fully empty state with all checkboxes unchecked). That way, when the administrator submits the form, all existing permissions will not be lost.
Remaining tasks
TBD
User interface changes
TBD
API changes
TBD
Data model changes
TBD
Release notes snippet
TBD
Comments
Comment #2
cilefen commentedThe error is actually (emphasis, mine):
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.
Comment #3
cilefen commentedThe 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.
Comment #4
smokrisIf 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 it 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.
Comment #5
cilefen commentedComment #6
cilefen commented