Store user ID with setting change written into changeset and restore user when setting is saved
|Reported by:||westonruter||Owned by:||westonruter|
In researching how best to accommodate Jetpack (#38672) being able to allow users who cannot unfiltered_css to be able to edit Custom CSS by adding additional sanitizing filters, I realized a deficiency in changesets (#30937). A supderadmin user user may write a change into a changeset, such as post_content, and this may include unsafe HTML as intended by the superadmin user. If non-super admin user comes along and makes a change to a different setting and updates the changeset, then if that non-super admin publishes the changes, the kses filters will unexpectedly strip out the unsafe markup content that the superadmin had written in their changeset update. This likewise will happen when a superadmin schedules their changeset for publishing later: when WP Cron runs there is no current user, and so the kses filters would apply then as well.
What is needed is for the user who modified a setting to have their user_id associated with the setting in the changeset. Then when the changeset is published with the settings being saved/persisted to the DB, then the associated user should be logged-in temporarily so that the setting will save with the expected user context. For normal user updates to changesets, this means that settings would no longer need to have their associated capability temporarily overridden to be exist.
Change History (6)
6 months ago
- Keywords has-unit-tests added
- Owner set to westonruter
- Status changed from new to accepted