[wp-trac] [WordPress Trac] #42477: Cannot save theme customizer changes if nonce_life value is filtered in the active theme

[WordPress Trac]

#42477: Cannot save theme customizer changes if nonce_life value is filtered in the
active theme
----------------------------+-----------------------------
 Reporter:  figureone       |      Owner:
     Type:  defect (bug)    |     Status:  new
 Priority:  normal          |  Milestone:  Awaiting Review
Component:  Customize       |    Version:  4.8.3
 Severity:  normal          |   Keywords:
  Focuses:  administration  |
----------------------------+-----------------------------
 Summary:

 If the `nonce_life` filter is used in the active theme to change the nonce
 lifetime from its default 86400 (e.g., to 3600), then changes made in the
 Theme Customizer cannot be saved.

 Details:

 WordPress 4.8 introduced some changes to the theme customizer, including
 this security-related commit that clears submitted post data if the nonce
 check fails:
 https://github.com/WordPress/WordPress/commit/3d10fef22d788f29aed745b0f5ff6f6baea69af3
 #diff-681a4f686cf806e75ff8cd4c6d2fe5b7

 This introduces an unintended side effect in a certain context:
 * Since this code is hooked into `setup_theme`, it fires before the theme
 is loaded.
 * If a theme developer hooks into the `nonce_life` filter that can be used
 to adjust the lifespan of nonces, it will cause the nonce check above to
 fail (since the nonce ticks will not match).
 https://developer.wordpress.org/reference/hooks/nonce_life/
 https://github.com/WordPress/WordPress/blob/master/wp-
 includes/pluggable.php#L1999

 This specific context happens in the theme customizer, when trying to
 //Save & Publish// changes. Interestingly, changesets can still be saved
 as an auto-draft on window blur (clicking outside of the browser window).
 I believe this is because changeset data is in
 `$_POST['customize_changeset_data']`, while the same data is in
 `$_POST['customized']` when the //Save & Publish// button is clicked.

 I think the best solution here may be to remove the `nonce_life` filter,
 but I don't know how widely it's used. Another possibility may be moving
 the nonce check out of `WP_Customize_Manager::setup_theme()`, but I don't
 have a good idea at the moment for where it should go.

--
Ticket URL: <https://core.trac.wordpress.org/ticket/42477>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform