An excerpt fromhttp://www.sitepoint.com/wp-api-and-oauth-using-wordpress-without-wordpress/, by @swader)
In this tutorial, we’ll learn how to install and use WP-API with OAuth – a WordPress plugin which uses REST-like API endpoints to allow reading of WP content to unauthenticated users, and writing of WP content to users who authenticate via OAuth (or via Cookies for themes and plugins).
Using the plugin isn’t very straightforward, and the prerequisite list is quite long, so this post was written to make it simple and relatively approachable (as long as you’re in control of your own server).
The tutorial assumes basic familiarity with the terminal, and with Vagrant for ease of development.
Installing
As usual, we’ll be using SitePoint’s trusty Homestead Improved instance to get a fresh environment up and running:
git clone https://github.com/swader/homestead_improved hi_wp_github
cd hi_wp_github
sed -i '' "s@map\: \.@map\: $PWD@g" Homestead.yaml
That last line is a shortcut that makes the current folder of the host machine shared into the VM’s Code folder. I also changed the sites block to:
sites:
- map: test.app
to: /home/vagrant/Code/wptest
Remember to have test.app (or the URL you choose) in your /etc/hosts file, as per instructions.
Next, we get a new instance of WP up and running. Since Homestead has MySQL pre-installed, this is a piece of cake.
cd ~/Code
wget https://wordpress.org/latest.tar.gz
tar -xvzf latest.tar.gz
mv wordpress wptest
cd wptest
cp wp-config-sample.php wp-config.php
After we update wp-config.php accordingly and set up our keys and database credentials, the WP instance is ready and can be finalized by running it in the browser.
WP-API
Despite the flak it’s taken over the years (a large part of it fired from my own Dual Flak Cannons), WP really is trying to get with the times while still accommodating their old, technically inept userbase.
One such effort is the WP-API, a REST-like set of endpoints built into WP as a plugin so that the internals of a WordPress installation can become accessible to the outside. For example, getting your posts in JSON format is as simple as pinging /wp-json/posts.
It can be easily installed via the default plugin manager – the stable version is 1.2.* at the time of this writing – so let’s do that.
If we test immediately after installation, the URL
/wp-json/posts should produce a JSON array of the initial “Hello World” post. However, the actual submission process (updating and posting) isn’t as simple.
OAuth – Server
Unfortunately, as with all things WP, even their attempts to be modern are already out of date.
As such, they use OAuth1 rather than OAuth2 for authentication. For that, we’ll need the OAuth1 plugin installed. For that, though, we need the wp-cli upgrade, a way to use WP commands from the terminal:
curl -O https://raw.githubusercontent.com/wp-cli/builds/gh-pages/phar/wp-cli.phar
chmod +x wp-cli.phar
sudo mv wp-cli.phar /usr/local/bin/wp
Then, we grab the OAuth plugin:
cd ~/Code/wptest
git clone https://github.com/WP-API/OAuth1 wp-content/plugins/oauth-server
Activate the plugin (which should now appear in the Plugins list) and back in the terminal run:
wp oauth1 add
This should produce a key / secret combination that can be used for OAuth authentication:
ID: 4
Key: xOp1fGMgouBl
Secret: Sk7YcM48qsmcDPp2NSmna3kMEfTtDNfxpy43xjWp1mSP7ytw
Aside from being out of date with their protocol approach, there’s also the problem of us having to use 3-legged OAuth rather than something simpler, UI-less like 2-legged OAuth flow. For differences, read this extensive guide. Hopefully, that’ll improve later.
The good news, though, is that if you’re the owner of the WP site and you’re enabling OAuth API access for others – you’re done! It’s up to them to develop a client, and that’s what we’ll do next.
OAuth – Client
To test submissions into WP via WP-API, we need an “app” to serve as the “submitter”. For that, we make a new project in another folder in the virtual machine – perfect for testing. First, we edit the virtual machine’s Homestead.yaml file to include a new site:
sites:
- map: test.app
to: /home/vagrant/Code/wptest
- map: test2.app
to: /home/vagrant/Code/submitter
Then, we exit the VM with exit and re-provision with vagrant provision and then re-renter the VM with vagrant ssh. Now that our submitter virtual host is defined, let’s add a simple index.php file into it, and a (for now) empty callback.php file.
mkdir ~/Code/submitter
touch ~/Code/submitter/index.php
touch ~/Code/submitter/callback.php
touch ~/Code/submitter/credentials.php
cd ~/Code/submitter
The credentials file should hold the keys we got from the WP app:
// credentials.php
<?php
return [
'consumer_key' => 'xOp1fGMgouBl',
'consumer_secret' => 'Sk7YcM48qsmcDPp2NSmna3kMEfTtDNfxpy43xjWp1mSP7ytw'
];
We’ll also need some packages installed:
composer require --dev symfony/var-dumper
composer require guzzlehttp/guzzle:~5
VarDumper is there to help us debug, and Guzzle 5 is there to help us issue requests at the WP-API. We could use a generic OAuth client, but why not use Guzzle’s?
composer require guzzlehttp/oauth-subscriber
Note that the submitter we’ll be building below is just a demo script, and should only be used as inspiration for implementing OAuth+WP-API in your own application, not as a full application demo.
One more thing – by default, WordPress blocks login redirections to external sites (those differing in domain) so a new filter needs to be added which will allow this. Back in the WP app’s sources, open default-filters.php and add the following somewhere into the file:
add_filter( 'allowed_redirect_hosts' , 'my_allowed_redirect_hosts' , 10 );
function my_allowed_redirect_hosts($content){
$content[] = 'test2.app';
return $content;
}
Naturally, replace test2.app with your own URL if you used a different one.