Add a 'rest_nonce_action' filter to the REST API

[enlightenedpie]

In the spirit of fully customizing the REST API, as I'm doing in my current application, some features (like the REST prefix) are customizable through filters, while the nonce name, or rather the rest nonce 'action', is not. 'wp_rest' is a bit generic and could easily have a 'rest_nonce_name' or 'rest_nonce_action' filter added in wp-includes/rest-api.php.

I believe in this regard that allowing alignment with user-defined namespaces and naming conventions would really further the extensibility of the WP REST API, especially in cases where pretty much every default (including default endpoints) are being disabled or overridden/overwritten. Thoughts?

[enlightenedpie]

Proposed change to rest-api.php (starts at line 780)

[schlessera]

Welcome aboard, @enlightenedpie , and thanks for the ticket!

To suggest code changes, you should upload them in the form of a patch, not the entire source file that you modified.

You can find more information about patches here: ​https://make.wordpress.org/core/handbook/contribute/#patches

Also, feel free to stop by in the ​#core channel on the make.wordpress.org Slack team if you have questions about the process.

[enlightenedpie]

rest-api.php patch

[enlightenedpie]

@schlessera Thank you for the heads up! Obvs my first time contributing. Patch submitted.

[schlessera]

@enlightenedpie No worries, we all start at some point.

There's something wonky with the alignment of your docblock (click on the patch name to see it). You should make sure you use tabs & spaces correctly. If you change the patch, you can just re-upload it and overwrite the previous version.

[enlightenedpie]

rest-api.php patch

[enlightenedpie]

@schlessera Thank you, doc block fixed. Although, when I uploaded the new patch I didn't see a way to replace the old one.

[TimothyBlynJacobs]

I wonder how practical using this filter would be. If a site changed the REST API action with that filter, all the plugins that were creating a wp_rest nonce to call the REST API would no longer work. As such, the practicality here seems quite small and would probably be better served by a custom authentication filter. Because of that I think it may make sense to close the ticket, conditionally adding a close keyword.