A nice little side effect of the development of WordPress’ Gutenberg block editor is that we now have a range of WordPress-oriented NPM packages available to us.
One such package that I’ve been using in recent development for the ACF Custom Database Tables plugin is the @wordpress/api-fetch package which, as its name implies, is all about fetching data from API’s.
When making requests to a public API, we can just go ahead use it without any need for authentication. The simplest example of this goes a little like this:
If a resource requires the user to have certain permissions, however, we need to send some information along with the request so WordPress can authenticate the user and check they have the correct permissions.
Whilst developing the upcoming field value migration feature, I’ve decided to move in the direction of a React-based UI that leverages the WordPress REST API and, as you might expect, these API endpoints need to be restricted to users with certain permissions — we wouldn’t want anyone kicking off migrations that modify a website’s data from a public API!
Fortunately, WordPress’ REST API has baked in support for cookie-based authentication and will do it all for us if we provide the
X-WP-Nonce request header, the value of which needs to be a nonce created using the
'wp_rest' action. e.g;
Looking at the REST API Handbook, we can see examples of how to set this header on an XHR object.
How to set the
X-WP-Nonce header when using
When using the
@wordpress/api-fetch package, things are a touch different to the standard approach and we actually have a couple of approaches available to us.
The first possible approach is to specify a
headers property in the object passed to
This is fine and works it would mean having to define that same property on all requests which can be problematic if we need to change it later.
@wordpress/api-fetch package supports adding middleware and provides us with a utility which handles the addition of the
X-WP-Nonce request header. We just need to tell the
apiFetch object to use nonce middleware and hand it our nonce. e.g;
The benefit of doing it this way is that we only define our nonce once and all requests will then have the
X-WP-Nonce request header. We also don’t have to worry about specifying the
X-WP-Nonce part as the package handles all that for us.
Making our nonce available to our script using
In the examples above, you’ll note that we are using a nonce at
window.myvars.nonce. This is something that I’ve added to the DOM using WordPress’ wp_localize_script() function. e.g;
It’s important to note that if we don’t do this step the nonce value won’t be available and our script will fail due to undefined variables. Also note that the action passed to
wp_create_nonce() must be
'wp_rest' or requests using this nonce will not authenticate.